mirror of
https://github.com/Hmbown/DeepSeek-TUI.git
synced 2026-09-03 06:50:13 +08:00
b596b6bfa3
A builder sub-agent could not run `echo x > file` in the workspace. Every `Bash` write came back with "cannot prove a bounded file target for this shared-workspace write claim", and the advice — use worktree isolation — puts the work in a sibling checkout the operator never looks at. Writing the same path through `File` was allowed the whole time, so the gate was not protecting anything the child could not already do. The gate asked whether *this* agent holds a shared write claim. The risk it exists for is a *peer* overwriting the same paths, and claims outlive the agents that register them: a test workspace with six `Completed` agents still held four standing claims, three of them non-isolated. So a lone builder was refused on account of children that had finished long ago, and a workspace got more restrictive the more it was used. `has_peer_shared_write_claim` now asks the real question: is another child, still `Running`, writing in this shared checkout. Worktree-isolated peers are excluded because they cannot contend for these paths, and an owner missing from the agent map stays contended — a claim that predates this session should fail closed. Concurrent writers are unaffected: `child_write_tool_fails_closed_outside_registered_scope` still passes unchanged, because it registers a live peer. A new test, `lone_shared_writer_keeps_unbounded_shell`, pins the case that was broken. Verified live against the release binary, in a workspace carrying those four stale claims: the builder ran `echo shell_fix2_ok > shell_fix2.txt` via `Bash`, exit 0, and the file landed in the workspace root — not in a worktree. Assisted by Claude Code.