Agent View / FleetView: allow specifying a starting directory (cwd) when spawning a new agent so it boots with the correct project context

Status Fixed / completed

Maintainer reply None cached

Activity 5 comments · opened May 20, 2026 · closed Jun 19, 2026

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

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 cwd in ~/.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 cwd for that agent template, the project the user is currently viewing, or a configurable default per agent type.
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:

Launch claude in the foreground in the target directory.
Type the request.
Wait until the request is acknowledged / the agent starts working.
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.

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

View original on GitHub ↗

4 Comments

github-actions[bot] · 3 months ago

Found 2 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

FrankLedo · 3 months ago

Thanks for the flag. These are related but not duplicates:

#60867 asks for a cwd parameter on the Agent tool itself — a programmatic API for orchestrating subagents across directories from within a running session. That's a different surface entirely.

#60972 asks for a cwd picker on the Desktop "+ New session" button (Windows), bundled with session-naming and CLI-to-Desktop visibility issues.

This issue is specifically about the Agent View TUI and FleetView/mobile dispatch path — when spawning from those surfaces, there's no way to pin the starting directory, so cwd-rooted project config (CLAUDE.md, .claude/skills, .mcp.json, project-scoped MCP servers) silently doesn't load for the new agent. The ask is a --cwd field threaded through the Agent View / FleetView spawn path.

All three touch cwd at session creation, but across three different surfaces with different implementation paths.

kcarriedo · 3 months ago

The cwd issue compounds quickly in real multi-project setups. The typical pattern is a shared daemon managing sessions across 3–5 different repos, and without explicit cwd on spawn, the agent either boots in ~ (missing all project config) or in whatever project happened to be the daemon's last context — which is often wrong.

The CLAUDE.md miss is the most painful part. If the file isn't discovered at startup, the agent proceeds without project conventions, security constraints, or skill definitions. You don't find out until the agent does something the CLAUDE.md was supposed to prevent.

A --cwd <path> flag on claude --bg dispatch would address this cleanly. A directory picker in the Agent View TUI would help even more for interactive users. For API/automation callers, being able to pass cwd in the dispatch payload directly (alongside the initial prompt) would be the most flexible surface.

(Working on Claudiverse, a coordination layer for Claude Code agent fleets — consistent cwd propagation on dispatch is one of the first config parity gaps we've had to work around.)

FrankLedo · 2 months ago

Closing this — there's an existing (but undocumented) behavior that already covers what I was asking for.

Starting a session by @-mentioning the project folder pins the session's working directory to it. e.g. launching with:

@myproject what are the rules for this project

starts the session with cwd = /Volumes/Projects/myproject (shown in the header) and loads that folder's CLAUDE.md. Since cwd is the root from which Claude Code discovers project-scoped config, pinning it this way is the spawn-time cwd this issue was after.

The gap is documentation: the docs only describe @ as file-path autocomplete / a file reference — there's no mention that referencing a folder sets the session working directory and loads that project's CLAUDE.md.

Leaving this note for anyone who hits the same thing. Closing as resolved-by-existing-behavior — worth the docs calling it out explicitly. (Confirmed on v2.1.183.)

Showing cached comments. Read the full discussion on GitHub ↗