claude-agent-sdk: forward the resolved working_dir to ClaudeAgentOptions.cwd

[jrob5756]

Summary

ClaudeAgentSdkProvider.CAPABILITIES declares working_dir=False, so conductor validate rejects any workflow setting agent.working_dir or runtime.working_dir against this provider.

Until #335 the stated reason was that MCP servers were rejected at the factory, so there was "nothing to scope by directory". That premise is gone — the provider now spawns MCP servers — and the comment was rewritten in #346 to give the real reason: the provider never forwards the engine-resolved working directory to ClaudeAgentOptions.cwd. The capability is still accurate, but it is now a plain gap rather than a consequence of another one.

Why it's worth closing

ClaudeAgentOptions has a cwd field (types.py:1699), so the plumbing is straightforward. Two things depend on it:

• The claude CLI itself runs in the resolved directory, matching what copilot and claude already do (feat(working-dir): working_dir for LLM agents and their MCP servers #297).
• Any stdio MCP server the CLI spawns inherits that cwd, so a server declared with a relative path behaves consistently across providers.

Today both silently use whatever directory the Conductor process happens to be in.

Scope

• Forward the resolved working_dir to ClaudeAgentOptions.cwd in execute().
• Flip CAPABILITIES.working_dir to True and update the comment at providers/claude_agent_sdk.py.
• Update the carve-out row in docs/providers/experimental.md and the parity notes in AGENTS.md.
• Mirror the existing working-dir tests for this provider (see feat(working-dir): working_dir for LLM agents and their MCP servers #297 for the pattern).

Worth confirming how cwd interacts with add_dirs and whether a non-existent directory should fail before the SDK call, matching the engine's existing behavior of raising an execution error for a missing target directory (docs/mcp-tools.md:259).

Related

• feat(working-dir): working_dir for LLM agents and their MCP servers #297 — working_dir for LLM agents and their MCP servers
• claude-agent-sdk provider: implement MCP server translation (mcp_tools=False is a gap, not an SDK limit) #335 / feat(claude-agent-sdk): support workflow MCP servers (#335) #346 — MCP server support, which invalidated the old justification
• docs: update docs/providers/experimental.md for the new working_dir capability carve-out #304 / docs(providers): document working_dir carve-out in experimental.md #305 — documenting the working_dir carve-out

[jrob5756]

Dug into claude-agent-sdk 0.2.82 to answer the two open questions at the bottom.

cwd vs add_dirs — they don't overlap. add_dirs becomes repeated --add-dir flags (_internal/transport/subprocess_cli.py:549-552); it widens which directories the CLI may touch and says nothing about where it starts. cwd is the real lever: subprocess_cli.py:135 stashes it, then passes it to open_process(cwd=...) at line 738 and sets PWD in the child env at 728. Conductor never sets add_dirs, so cwd alone is enough.

Non-existent directory — already covered upstream. WorkflowEngine._resolve_agent_working_dir (engine/workflow.py:517) raises ExecutionError before the provider is called, so the SDK's own CLIConnectionError("Working directory does not exist") (subprocess_cli.py:763) is unreachable through the engine. No extra guard needed.

One shape difference from Copilot: there's no per-server stamping to do. McpStdioServerConfig (types.py:603) has only type/command/args/env, no cwd field, so stdio servers pick the directory up by inheriting it from the claude subprocess. _translate_mcp_servers and _write_mcp_config stay as they are.

Worth a doc line: cwd also decides which CLAUDE.md and local settings the CLI loads, and it's the session-store project key (_internal/session_resume.py:143). Probably what you want, and strict_mcp_config=True already stops a .mcp.json in the new directory from loading.

[jrob5756]

Starting to take a look at this.