The destructive side is safe: removeTaskWorktree(cwd, taskId, …) recomputes the path from taskWorktreePath(cwd, taskId) (task-worktree.ts:546) and never reads record.worktree, and taskId is filtered by isTaskId before any join (tasks-store.ts:206, same in removeTaskDir).
The read/execute side is not. In the contract, worktree is only a length-bounded string — packages/contract/src/tasks.ts:844:
worktree: str(r.worktree, TASK_PATH_MAX), // TASK_PATH_MAX = 500, no shape constraint
That string is then used as-is as a cwd:
task-runner.ts:1421 — git statustask-runner.ts:1427 — git add -Atask-runner.ts:1430 — committask-runner.ts:2241 — the agent's cwdtask-review.ts:359, task-checks.ts:862, task-checks.ts:1026, task-retention.ts:165
There is no startsWith(project.path) and no relative() check on any of these. The only path-escape guard in the codebase is container-git.ts:63, which validates the --git-dir link — unrelated.
Scenario: a task.json that is corrupted or hand-edited so that "worktree" points elsewhere (say /home/x/other-repo) → on the next turn ensureWorktree sees existsSync(record.worktree) as true and skips rematerialisation (task-runner.ts:1852), then the agent runs and git add -A && git commit lands in the other repository.
Low likelihood (it takes a corrupted or edited store), which is why this is minor — but the blast radius is someone else's repo, and the fix is small.
Suggested direction
Validate record.worktree before using it as a cwd: check containment in project.path with relative(), the way container-git.ts:63 already does for the git link. On failure, treat it as "rematerialise" rather than "execute".
Found while auditing a competitor harness (internal Ruflo audit): their worktree coordinator validates registry paths against escape on every read.
The destructive side is safe:
removeTaskWorktree(cwd, taskId, …)recomputes the path fromtaskWorktreePath(cwd, taskId)(task-worktree.ts:546) and never readsrecord.worktree, andtaskIdis filtered byisTaskIdbefore anyjoin(tasks-store.ts:206, same inremoveTaskDir).The read/execute side is not. In the contract,
worktreeis only a length-bounded string —packages/contract/src/tasks.ts:844:That string is then used as-is as a
cwd:task-runner.ts:1421—git statustask-runner.ts:1427—git add -Atask-runner.ts:1430— committask-runner.ts:2241— the agent's cwdtask-review.ts:359,task-checks.ts:862,task-checks.ts:1026,task-retention.ts:165There is no
startsWith(project.path)and norelative()check on any of these. The only path-escape guard in the codebase iscontainer-git.ts:63, which validates the--git-dirlink — unrelated.Low likelihood (it takes a corrupted or edited store), which is why this is minor — but the blast radius is someone else's repo, and the fix is small.
Suggested direction
Validate
record.worktreebefore using it as acwd: check containment inproject.pathwithrelative(), the waycontainer-git.ts:63already does for the git link. On failure, treat it as "rematerialise" rather than "execute".Found while auditing a competitor harness (internal Ruflo audit): their worktree coordinator validates registry paths against escape on every read.