feat: per-thread isolated working directories

[qijie850]

Problem

Currently all Discord threads share the same working_dir (from config). When multiple threads run concurrently, their coding agents operate in the same directory, which can cause file conflicts and unexpected behavior.

Proposed Solution

Create a unique subdirectory for each thread under working_dir:

<working_dir>/sessions/<thread_id>/

Each AcpConnection spawns into its own isolated directory, so parallel sessions never interfere with each other.

Implementation

Minimal change in pool.rs — create the per-thread directory before spawning the agent and pass it as the cwd:

// In get_or_create(), before spawning:
let thread_dir: PathBuf = [&self.config.working_dir, "sessions", thread_id].iter().collect();
tokio::fs::create_dir_all(&thread_dir).await?;
let thread_dir_str = thread_dir.to_string_lossy().to_string();

let mut conn = AcpConnection::spawn(
    &self.config.command,
    &self.config.args,
    &thread_dir_str,  // per-thread dir instead of shared working_dir
    &self.config.env,
).await?;

conn.initialize().await?;
conn.session_new(&thread_dir_str).await?;

Additional Considerations

• Cleanup: Should idle session directories be cleaned up when cleanup_idle removes stale connections?
• Git worktree: An alternative approach could use git worktree for repo-based workflows, but simple directory isolation covers the general case.
• Config opt-in: Could add a config flag like isolate_sessions = true if backward compatibility is a concern, though isolated dirs seem like a safer default.

Happy to submit a PR if this direction looks good. We've already tested this locally and it works well with claude-agent-acp.

[ruan330]

Great proposal! This solves the isolation problem cleanly.

One additional use case to consider: routing threads to existing project directories.

In our setup, we have multiple projects (e.g., finance-app/, health-tracker/) and want each thread to work inside a
specific existing project — with its own CLAUDE.md, .claude/settings.json, git repo, etc.

Auto-creating sessions/<thread_id>/ solves isolation, but starts with an empty directory (no project context). A
combined approach could support both:

1. Default (no directive): auto-isolate into sessions/<thread_id>/ — your proposal, works great for ad-hoc tasks
2. Explicit CWD override: user specifies an existing directory in the first message — the session uses that instead

For example, a structured message prefix:

@bot [cwd:/path/to/my-project] implement the login feature

The pool would check: if a CWD directive is present, use that path; otherwise, fall back to the auto-created
sessions/<thread_id>/ directory.

This keeps backward compatibility, covers the isolation case by default, and adds project routing as an opt-in.

Would be happy to collaborate on a PR if this direction sounds good.

[thepagent]

Thanks for the well-thought-out proposal and the implementation sketch! This is a real problem — shared working_dir across concurrent threads is bug-prone.

Current (shared):
/home/agent/
├── file-from-thread-A    ← conflict!
└── file-from-thread-B    ← conflict!

Proposed (isolated):
/home/agent/sessions/
├── 1234567890/           ← thread A
│   └── (agent workspace)
└── 9876543210/           ← thread B
    └── (agent workspace)

The sessions/<thread_id>/ approach looks good. A few notes:

• Default isolation on (no config flag needed) — shared dirs are the unsafe case
• Cleanup should tie into cleanup_idle — remove the directory when the session is reaped
• The [cwd:/path] directive from @ruan330's comment is a nice extension but should be a follow-up

Note: #40 (/close command) depends on this for full cleanup. Suggested order:

#38 per-thread dirs ──> #40 /close + cleanup
      (land first)         (depends on #38)

Happy to review a PR!

[thepagent]

For reference, looked at how OpenClaw handles this. Their architecture is more complex (multi-agent orchestrator), but some patterns worth borrowing:

OpenClaw's thread session management (Discord slash commands):

• /focus <session> — bind a thread to a specific agent session
• /unfocus — detach without killing
• /agents — list active sessions and binding state
• /session idle <duration|off> — per-thread idle timeout
• /session max-age <duration|off> — per-thread max lifetime

Source: https://github.com/openclaw/openclaw/blob/main/docs/tools/subagents.md

What we could adopt incrementally:

Phase 1 (#38): auto-isolated sessions/<thread_id>/
Phase 2 (#40): /close as Discord slash command
Phase 3: /new slash command with optional cwd + topic
         /new                          → auto-isolated dir
         /new cwd:/path/to/project     → existing project dir
         /new topic:"fix bug" cwd:/app → custom thread title + cwd
Phase 4: /session idle, /session max-age (per-thread TTL)

This keeps things simple now while leaving room to grow toward OpenClaw-level thread management.

[qijie850]

Thanks for the feedback! PR submitted: #41

Kept it minimal — just pool.rs, default isolation on, and cleanup in cleanup_idle as you suggested. The [cwd:/path] directive from @ruan330 is a great idea for a follow-up.

Also opened #42 for the /close command, based on your branch ordering suggestion (#38 first → #40 second).

[neilkuan]

Nice work on the per-thread directory isolation — it's the right first step and covers the general chat/Q&A use case well.

One thought for a future iteration: it might be worth designing the config to support multiple isolation strategies. Something like:

[agent]
isolation = "directory"   # default, current behavior
# isolation = "worktree"  # future: git worktree per thread
working_dir = "/repo"

Why worktree mode matters:

With directory mode, each thread gets a clean empty folder — great for conversational use, but the agent has no codebase or git history to work with. For repo-based coding workflows (the kind where you actually want the agent to read, modify, and commit code), git worktree add per thread would give each session:

• Full codebase access (shared .git object store, no duplication)
• Branch-level isolation (no file conflicts between threads)
• Mergeable results (git merge back to main)
• Cleanup via git worktree remove

Implementation sketch:

1. In get_or_create(), check if working_dir is a git repo (at startup, not per-session)
2. If isolation = "worktree": git worktree add -b thread/<thread_id> sessions/<thread_id> HEAD
3. Cleanup: git worktree remove --force sessions/<thread_id> && git branch -D thread/<thread_id>
4. If isolation = "worktree" is set but working_dir isn't a git repo, fail loudly (don't silently fall back — that hides config mistakes)

A few implementation gotchas worth noting upfront:

• Dirty worktree on cleanup: git worktree remove fails if there are uncommitted changes. Need --force, otherwise cleanup silently breaks and worktrees accumulate on disk.
• Branch already exists on reconnect: If a session crashes and reconnects, git worktree add -b thread/<id> will fail because the branch already exists. Need to check first or use --detach.
• sessions/ inside the repo pollutes git status: If working_dir is the repo root, the sessions/ directory will appear as untracked. Add it to .gitignore.
• Concurrent worktree creation: Parallel get_or_create() calls for different threads can race on git's internal lock files (.git/config.lock). Worth serializing git operations or catching the lock error and retrying.

Not suggesting any of this needs to be in the current PR — the directory approach is a solid phase 1. Just flagging the gotchas so the isolation config field stays on the table as a clean extension point later.

[thepagent]

@qijie850 Before we dive into implementation, could you walk us through the specific use cases you're running into? I'd love to understand more about what kind of tasks your threads are handling concurrently and what conflicts you've hit with the shared working directory. That'll help us figure out the right approach — whether it's per-thread isolation by default, an opt-in config flag, or something like git worktrees for repo-based workflows.

[qijie850]

Our setup: we run a product (Next.js monorepo) with multiple coding agents working on it concurrently through agent-broker. A typical scenario looks like:

• Thread A: agent fixing a frontend bug on fix/login-redirect
• Thread B: agent implementing a backend API on feat/user-export
• Thread C: agent refactoring a frontend component on refactor/dashboard

With a shared working directory, these agents step on each other — git checkout in one thread blows away uncommitted changes in another, or files created by Thread A leak into Thread B's context.

What we've been doing: git worktrees. Each task gets its own worktree so agents can work on different branches simultaneously without interference. This is the pattern we'd eventually like agent-broker to support natively.

The per-thread sessions/<thread_id>/ directory (#41) solves the immediate isolation problem for ad-hoc tasks. But for our main use case — concurrent work on the same repo across different branches — the ideal next step would be something like @neilkuan's isolation = "worktree" suggestion, where agent-broker creates a git worktree per thread automatically.

Short-term, #41 unblocks us. Long-term, worktree-based isolation would be the real win.