fix(server): read workflow scripts from configured Claude homes#21970

🟠 High orchestration-v2/workflowScriptQuery.ts:31

When CLAUDE_CONFIG_DIR is relative, this query searches under the server cwd and rejects workflow scripts that are under the session’s config root. resolveClaudeHomePath receives no session cwd here, unlike the workflow-file resolution in ClaudeAdapterV2.ts; resolve the relative value against the session cwd consistently.

No longer relevant as of 0c3d2edb11b1203152fcb3ebc6f519c883441e67

Fixed in 0c3d2ed. The existing typed threadId is forwarded by WS; the query derives persisted worktree cwd, falling back to project workspace root. Only inherited relative CLAUDE_CONFIG_DIR uses that cwd; explicit homePath retains server normalization and precedence. The real persisted-thread/temp-checkout regression failed before and now passes, with all 8 workflow/transcript cases green. Both R5 reviewers verified the full layer.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Isolate the test from the host Claude environment.

If the test process sets CLAUDE_CONFIG_DIR to a path outside the sandbox, the built-in Claude instance uses that path instead of home/.claude. The default-home read at Line 87 then fails with outside-root. Provide a controlled HostProcess.Environment in this test layer so the result does not depend on the developer’s or CI host environment. HostProcess.Environment defaults to process.env. (raw.githubusercontent.com)

✅ Addressed in commits e99cdae to 0c3d2ed

Fixed in 0c3d2ed. The fixture provides HostProcess.Environment = {} alongside its temporary home; configured, inherited, default-root and containment controls pass. This removes host CLAUDE_CONFIG_DIR dependence.

@juliusmarminge Thanks. The supplied fixture now provides HostProcess.Environment = {} alongside the temporary home. This removes dependence on the host’s CLAUDE_CONFIG_DIR and addresses this finding.

✅ Review thread resolved.

You are interacting with an AI system.

📐 Maintainability & Code Quality | 🟠 Major | 🏗️ Heavy lift

Move workflow-script lookup into a domain service.

readWorkflowScript now coordinates thread lookup, settings, environment resolution, and file reads as a standalone Effect.fn. Put this capability on a domain service. Keep the WebSocket handler as a call to that service method. As per coding guidelines, “A server capability is a method on a service in its domain folder.” As per path instructions, “Server capabilities belong in domain services.”

Sources: Coding guidelines, Path instructions

The expanded readWorkflowScript now resolves persisted threads, settings, environments, and files but remains an exported effectful function called directly by the WebSocket handler. Consider moving this capability onto an orchestration-domain Effect service and having the handler call that service method; keep this function only as a private implementation detail if needed. This requires coordinated service/layer and consumer changes.

^{Posted via Macroscope — Effect Service Conventions}

The missing-project branch above produces a structured OrchestrationWorkflowFileError with root-unavailable, but this blanket mapping turns it into read-failed. Consider translating that known failure to the corresponding workflow-script reason at the branch, and mapping thread/settings/environment failures at their respective boundaries instead of wrapping the entire root-resolution pipeline. This needs changes at multiple locations.

^{Posted via Macroscope — Effect Service Conventions}