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.mddiscovery walks up fromcwd..claude/skills/,.claude/agents/,.claude/settings.json,.mcp.jsonare all resolved relative tocwd(project scope) or~/.claude(user scope).- MCP servers configured at project scope only attach when started in that project.
- Plugins and
.claudeignoreare likewisecwd-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
- Open the Agent View (
claude agents) or dispatch a new agent from FleetView / mobile. - Start a new agent with a task like "summarize the latest PRs in repo X".
- Observe the new session's
cwdin~/.claude/jobs/<short>/state.json— it is not the repo the task is about; it's the dispatcher's default. - 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:
- Accept an explicit starting directory (path picker or freeform field).
- Default to a sensible candidate — e.g. the last
cwdfor that agent template, the project the user is currently viewing, or a configurable default per agent type. - Persist the chosen
cwdinto~/.claude/jobs/<short>/state.jsonand 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'scwd. - 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
claudeCLI has no--background(or equivalent) flag that spawns the new agent directly into the background pool from a terminal. You have to:
- Launch
claudein the foreground in the target directory. - Type the request.
- Wait until the request is acknowledged / the agent starts working.
- Then
/bgto 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
--backgroundflag existed, this would still be a workaround for the real gap: the Agent View / FleetView spawn path itself should accept acwd.
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).
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗