Worktree-Isolated Multi-Agent Runs with Secure Manager Logs

[SivanCola]

Summary

Adds a first-class agents tool for coordinated multi-agent runs, including read-only parallel exploration, worktree-isolated write agents, DAG dependencies, branch/commit summaries, merge planning, and desktop visibility for nested agent activity.

Root Cause

The previous sub-agent flow could delegate focused work, but it did not provide a durable manager-level contract for physically isolated write agents, branch/commit receipts, or persisted run state. Plugin/MCP tools also needed to be rebound per worktree so child agents operate against the intended workspace instead of the parent process directory.

Technical Approach

• Introduce an agents batch tool that runs up to four sub-agents with per-agent session or worktree isolation, read_only or write mode, DAG depends_on ordering, and branch/worktree defaults.
• Add git worktree creation, commit detection, dirty-state blocking, merge planning, optional auto-merge, and cleanup handling.
• Rebind built-in workspace tools and explicitly requested MCP/plugin tools to each worktree; stdio plugin specs are deep-copied and restarted with the worktree directory.
• Persist manager run events as append-only JSONL logs under the Reasonix config directory.
• Surface nested multi-agent activity in CLI/ACP/desktop transcripts, including branch/worktree/status metadata and a desktop open-folder action.

Focused Optimization Points

• Manager run logs use private permissions (0700 directory, 0600 files) and redact full agent prompts while preserving prompt byte counts for auditability.
• Worktree paths are constrained to relative directories under the repository parent and reject absolute paths, .. escapes, . roots, and symlink escapes.
• Desktop OpenPath is restricted to the current workspace, registered git worktrees, and manager-run logs; it rejects arbitrary files and .app bundles.
• Worktree agents no longer start all configured MCP/plugin servers by default. Plugin rebinding now happens only when an mcp__... tool is explicitly requested.
• Read-only worktree agents are blocked if they dirty the worktree or create commits.

Verification

• go test ./...
• (cd desktop && go test ./...)
• npm --prefix desktop/frontend run build
• git diff --check

[SivanCola]

@codex review

[SivanCola]

CI follow-up: fixed the Ubuntu failure by configuring a local git identity in the test repository used by TestAgentsManagerActionsMergeAndCleanup, so the test merge commit no longer depends on runner-global git config. The subsequent macOS failure was an actions/setup-go DNS failure before project code ran; I retriggered CI with an empty commit because I do not have admin rights to rerun jobs directly.\n\nVerification:\n- env HOME=$(mktemp -d) go test ./internal/agent -run TestAgentsManagerActionsMergeAndCleanup -count=1\n- go test ./...\n- go vet ./...\n- gofmt check for the root module\n- git diff --check\n\nLatest GitHub checks are now green on ubuntu-latest and macos-latest.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 14c995e44e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[esengine]

The worktree isolation and the 0600/0700 manager run-logs are genuinely nice pieces of engineering, and I read through the whole thing.

I can't take the core of it, though. The agents tool is model-facing — the model itself can spawn up to four parallel sub-agents, with writable worktrees and a depends_on DAG. Model-driven sub-agent spawning is the one pattern we've already measured and rejected: in our runs it loses badly to flat execution (spawn storms), and parallel fan-out is a direct token-cost multiplier, which cuts against the cheapness the project is built on. That's also why #2463 is fine and this isn't — #2463 is strictly user-invoked with disable-model-invocation and never touches the model's spawn surface; this exposes spawning straight to the model.

If you want to land the useful parts, the path is the #2463 shape: a user-invoked skill with disable-model-invocation, not a model tool — and the worktree/secure-log plumbing could come along with it. Closing this version on the architecture call; the craft isn't the issue.