Let chat sessions run in a user-specified local directory (per-session working dir)

[beastpu]

Summary

The local_directory binding (run an agent in-place in a real local dir instead of a git worktree) currently only exists at the project level, so it only reaches issue tasks and project-scoped quick-create. Chat sessions can never use it — which means to make a chat agent work in a specific local folder you have to ask it to cd on every turn. This is a proposal to let a chat session run in a user-specified local directory, and a question of whether it's worth doing upstream.

The gap

• chat_session has no project link (creating one only takes agent_id + title).
• The daemon's chat-task claim branch never attaches project_resources, so findLocalDirectoryAssignment always resolves to nil for chat tasks → they never enter the in-place path.

Net effect: CLI agents (Claude Code / Codex) treat the current working directory as session context with zero setup; chat has no equivalent, so you either cd every turn or bind a whole project.

Why this fits the existing architecture

The in-place execution machinery already exists and is path-driven, not project-specific:

• validateLocalPath — blacklist + symlink double-resolve + read/write probe
• LocalPathLocker — per-path serialization
• execenv LocalWorkDir / LocalDirectory — in-place, no worktree
• CleanupSidecars — restore the user's dir afterward

The only thing hard-wired to project resources is the source-resolution step. chat_session even already has a work_dir column (currently daemon-backfilled for session resume). So the missing piece is an input path + wiring, not new execution logic.

Proposed direction (minimal)

A session-level optional working directory, desktop + local-daemon only:

• Store an explicit bound_work_dir + bound_daemon_id on chat_session, kept separate from the backfilled work_dir so it doesn't clash with prior-session reuse.
• Session binding takes precedence over project resources; everything downstream (validate / lock / in-place / cleanup) is reused unchanged.
• Excluded by construction: cloud runtime, web, and channel-originated (Slack/Lark) sessions — a channel message must never be able to bind or run against a local path.
• Settable at session creation and/or from the composer; show the privacy-stripped bound path in the session header so it's always visible (an agent that edits real files in a real dir should never do so invisibly).

Open questions for maintainers

1. Scope — is per-session local-dir binding something you'd want upstream, or intentionally out of scope for chat?
2. Entry model — per-session explicit binding, a project-level default that new sessions inherit, or both (session overrides project)? I lean toward per-session explicit + a visible prefill of the agent's last-used dir, rather than silent inheritance — silently writing files into a dir the user forgot they set is risky.
3. Offline / mismatched daemon — should the task wait for the bound machine, or fall back to a temp worktree? I lean toward wait, to avoid "thought it ran in my repo, actually ran in a temp dir".

I have a working design + PR breakdown and am happy to contribute it upstream if there's interest.