Sandbox blocks Git write ops on worktree workspaces — allow worktree-linked paths without trust_mode

[linletian]

Background

I use Git worktrees to organize my projects. My workspace looks like:

~/Projects/main-repo/              ← main repo
~/Projects/main-repo-wt/feat-x/    ← worktree workspace (created via git worktree add)

A worktree .git is just a pointer file:

gitdir: /Users/xxx/Projects/main-repo/.git/worktrees/feat-x/

The actual Git metadata (index, refs, objects, HEAD) lives inside the main repo, NOT inside the worktree workspace directory.

The problem

When I open this worktree directory in codewhale Agent mode, all Git write operations fail:

fatal: Unable to create .../index.lock: Operation not permitted

The reason is straightforward: codewhale sandbox only allows writes within the workspace directory, but the worktree Git metadata is at an external path (/Users/xxx/Projects/main-repo/.git/), so everything gets blocked.

Reads work fine — git status, git diff, git log all work through the structured tools, which means codewhale CAN read the external .git paths. Only writes are blocked.

Current workarounds

Either switch to YOLO mode (which implies trust_mode=true, granting blanket write access to all external paths), or quit codewhale and run git commands manually in a separate terminal. Neither is great. YOLO mode opens up write access everywhere, which feels unsafe. Switching to a terminal breaks the codewhale workflow.

What I hope for

Let codewhale handle Git write operations in worktree workspaces without enabling trust_mode.

Each worktree has two natural path pointers that codewhale can already read:

1. Worktree metadata dir: the .git file contains gitdir: .../main-repo/.git/worktrees/<name>/
2. Shared Git dir: the commondir file inside the metadata dir (content is ../.. or similar) resolves to the main repo .git/ directory

Just whitelist these two paths for writes. No other external paths need to be touched. The risk is minimal — these are just the same repository Git metadata directories. This is much safer than the blanket trust_mode=true.

Environment

• macOS Sequoia
• codewhale v0.8.58
• Git worktree, Agent mode

To reproduce

git worktree add ~/worktree-dir feature-branch
# Open ~/worktree-dir in codewhale Agent mode
git add -A
# fatal: Unable to create '.../index.lock': Operation not permitted

Would love to see codewhale handle worktree-linked external paths so Git operations work smoothly in Agent mode.

[github-actions]

Thanks @linletian for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[linletian]

Thanks for the prompt response. Here are the details requested.

Reproduction

1. Open a Git worktree in Agent mode

git worktree add ~/worktree-dir feature-branch
# Then open ~/worktree-dir in codewhale Agent mode

2. Run any Git write command

git add -A

3. Error in Agent mode

fatal: Unable to create '/path/to/main-repo/.git/worktrees/feature-branch/index.lock': Operation not permitted

Also fails identically with: git commit, git fetch, git reset --hard, git push

4. In YOLO mode (trust_mode=true)

All Git write operations succeed without error.

---

Environment

Item	Value
codewhale	0.8.58 (0181493c791f)
OS	macOS 13.7.8 (Ventura 22H730), x86_64
Shell	/bin/zsh
Git	2.39.2 (Apple Git-143)
Sandbox	macos-seatbelt (active, confirmed via codewhale doctor)
Provider	deepseek, model deepseek-v4-pro
Mode	Agent (without trust_mode)

Worktree configuration

$ git worktree list
/Users/.../main-project                                                                       3e417b5 [develop]
/Users/.../main-project-wt/feature-branch                                                     47dc43f [feature-branch]

Worktree .git pointer

$ cat .git
gitdir: /Users/.../main-project/.git/worktrees/feature-branch

Shared Git directory (commondir)

$ cat /Users/.../main-project/.git/worktrees/feature-branch/commondir
../..

→ resolves to: /Users/.../main-project/.git/

codewhale doctor output (full)

codewhale 0.8.58 (0181493c791f)
rust: rustc 1.93.1 (01f6ddf75 2026-02-11)

Platform:
  OS: macos
  Arch: x86_64
  ✓ sandbox available: macos-seatbelt

Workspace: ~/worktree-dir

Provider: deepseek
  base_url: https://api.deepseek.com/beta
  model: deepseek-v4-pro
  ✓ API connection successful

Root cause analysis

The sandbox macos-seatbelt correctly enforces a write boundary at the workspace root. The problem is that the write boundary does not account for Git worktree-linked external paths:

• Workspace root (writable): ~/worktree-dir/
• Worktree metadata dir (needs writes, currently blocked): ~/main-project/.git/worktrees/feature-branch/
• Shared .git dir (needs writes, currently blocked): ~/main-project/.git/

Both paths are unambiguously derivable from the worktree .git file and the commondir file — no heuristics needed.

Note

The error reproduced reliably in Agent mode earlier today. At the time of writing this comment I am in YOLO mode (to collect diagnostics), so git add succeeds. The failure is specific to Agent mode without trust_mode.

[Hmbown]

Thanks @linletian for the detailed worktree repro and diagnostics. This is now carried locally in the v0.8.64 integration branch via the harvested @cyq1017 fix from PR #3356, plus a follow-up that resolves the worktree .git pointer from ancestor directories so commands launched from subdirectories are covered too.

Local verification included:

• cargo test -p codewhale-tui --bin codewhale-tui --locked workspace_write_includes_git_worktree_metadata_roots
• cargo test -p codewhale-tui --bin codewhale-tui --locked workspace_write_resolves_git_worktree_metadata_from_subdirectory

I am leaving this issue open until the integration branch is pushed/landed so the public repo state stays accurate.