claude-code - 💡(How to fix) Fix Agent View / FleetView: allow specifying a starting directory (cwd) when spawning a new agent so it boots with the correct project context

Summary

When spawning a new agent/session from the Agent View (claude agents TUI, or the FleetView/mobile dispatcher), there is no way to force the new process to start in a specific folder. The new agent inherits a default cwd and therefore boots without the correct project context — no project CLAUDE.md, no .claude/ skills, no per-project MCP server config, no .claudeignore, no project-scoped settings.

The practical effect: an agent dispatched to "do work on repo X" frequently starts in ~ or in whatever cwd the daemon picked, then has to re-discover the repo before it can do anything useful — and in many cases it doesn't, because the project-scoped configuration is only loaded at startup.

Why this matters

Project context in Claude Code is cwd-rooted:

• CLAUDE.md discovery walks up from cwd.
• .claude/skills/, .claude/agents/, .claude/settings.json, .mcp.json are all resolved relative to cwd (project scope) or ~/.claude (user scope).
• MCP servers configured at project scope only attach when started in that project.
• Plugins and .claudeignore are likewise cwd-scoped.

If the spawning UI doesn't let me pin the cwd, none of the above loads correctly for the new agent. That is a silent loss of context, not an error the user sees.

Reproduction

1. Open the Agent View (claude agents) or dispatch a new agent from FleetView / mobile.
2. Start a new agent with a task like "summarize the latest PRs in repo X".
3. Observe the new session's cwd in ~/.claude/jobs/<short>/state.json — it is not the repo the task is about; it's the dispatcher's default.
4. The agent does not pick up that repo's CLAUDE.md, project skills, or .mcp.json.

Expected behavior

When creating a new agent from any spawn surface (Agent View TUI, FleetView, mobile, daemon dispatch), the UI should:

1. Accept an explicit starting directory (path picker or freeform field).
2. Default to a sensible candidate — e.g. the last cwd for that agent template, the project the user is currently viewing, or a configurable default per agent type.
3. Persist the chosen cwd into ~/.claude/jobs/<short>/state.json and use it as the actual working directory of the spawned process, so all project-scoped config resolves correctly at startup.

Suggested implementation

• Add a --cwd <path> flag (or equivalent dispatch field) to the spawn path used by the Agent View / FleetView / daemon, threaded through to the child process's cwd.
• In the Agent View TUI, add a directory field to the "new agent" form (with tab-completion against known project roots from ~/.claude/projects/).
• In FleetView / mobile, add a "Working directory" selector in the dispatch sheet, populated from recent project cwds on that host.

Workaround

Today you have to start the agent from a terminal already cd'd into the right repo, which defeats the point of dispatching from the Agent View / mobile. And even that workaround is awkward:

• The claude CLI has no --background (or equivalent) flag that spawns the new agent directly into the background pool from a terminal. You have to:
  1. Launch claude in the foreground in the target directory.
  2. Type the request.
  3. Wait until the request is acknowledged / the agent starts working.
  4. Then /bg to push it to the background.
• This means the user has to babysit the spawn just to get cwd right — they can't fire-and-forget from a script or hotkey.
• Even if a --background flag existed, this would still be a workaround for the real gap: the Agent View / FleetView spawn path itself should accept a cwd.

Secondary impact: Agent View sorting

This also affects the Agent View display when sorted by "tasks per folder" (or any cwd-grouped view). Because the dispatcher-picked cwd doesn't match the repo the task is actually about, agents get bucketed under the wrong folder — or under a generic ~/dispatcher default — making the per-folder rollup misleading. Fixing the spawn-time cwd selection fixes the grouping for free.

Related

• #60437 — Agent View doesn't enumerate FleetView-dispatched sessions (visibility, the inverse direction).