[FEATURE] Desktop: add a directory to a running local session (local equivalent of --add-dir / the cloud + button)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been requested yet
• [x] This is a single feature request

What Problem Does This Solve?

A local Code-tab session is bound to the folder chosen when it was created. There is no way to widen that scope afterwards. The docs confirm it: in the CLI-flag comparison, --add-dir maps to "Add multiple repos with the + button in cloud sessions" — cloud only, with no local equivalent.

That assumes you know the full scope of the work before you start it. In practice you often don't. A session opened in one service's repository discovers mid-run that the fix belongs in the infrastructure repo, or in a sibling service, or in a shared library. At that point the session hits the working-directory boundary and the work stalls — the model starts narrating its way around a wall (cd refused, so it tries Glob/Grep, which are scoped too) instead of doing the task.

The terminal CLI does not have this problem in practice, because people launch claude from a directory that already contains everything — often $HOME. The desktop app's folder picker makes the narrow scope the default, so the boundary is hit far more often there.

Proposed Solution

Give local sessions the same affordance cloud sessions already have: a + button (or a /add-dir equivalent) that adds a directory to the running session's scope, without restarting it or losing context.

Ideally the permission prompt could offer this inline — when a tool call is refused because the path is outside the working directory, offer "add this directory to the session" alongside deny, the same way other permission prompts offer a persistent choice.

Alternatives Considered

• permissions.additionalDirectories in settings.json — works, and is what I settled on. But it requires predicting the scope ahead of time and applies to every session globally, which is a blunter grant than the situation calls for: a session that needs one sibling repo today gets standing access to everything listed, forever.
• Starting the session at a parent folder — sidesteps the boundary, but you must know in advance that you will need it, which is exactly the information you lack. It also loses the per-repo automatic worktree, since the worktree follows the folder the session was opened in.
• Restarting the session in a wider folder — loses the session's context, which is the whole reason for wanting to continue in place.

Environment

• Claude Desktop: 1.24012.11 (Linux beta, apt)
• Applies to local sessions on every platform, not Linux-specific