app-server-broker.mjs daemon persists with deleted-worktree cwd and gets re-assigned across repos

Issue

app-server-broker.mjs daemons survive their owning worktree being removed (git worktree remove or rm -rf) and keep running with cwd pointing to the deleted directory. On a later dispatch from an unrelated repo, an orphan broker is re-assigned to that new dispatch. Shell ops partially succeed, then fail at the first cwd-rooted op (e.g. git add), producing a silent stall.

Reproduce

1. In repo A, create worktree X and start a Codex dispatch — broker spawns with cwd=A/.../X.
2. git worktree remove X (or rm -rf X). The broker is not killed.
3. Later, in repo B, start a new Codex dispatch.
4. Expected: a new broker spawns with cwd=B/.../Y.
5. Actual: the orphan broker (cwd points to deleted A/.../X) is re-assigned. The dispatch stalls at the first git op.

Evidence

/proc/<pid>/cwd of orphan brokers resolves to a path suffixed " (deleted)". In one snapshot, two orphans (cwd in deleted kbase worktrees) coexisted with live brokers; a new dispatch from a third repo (claude-config) produced no new broker — an orphan was reused instead.

Shared sandbox lock /tmp/codex-bwrap-synthetic-mount-targets-1001/lock is touched by every codex process and looks like the rediscovery path that lets orphans be re-elected.

Expected behavior

Any one of:

• Broker self-terminates on startup if its cwd no longer exists.
• Broker is killed when its owning worktree is removed (lifecycle hook).
• Re-assignment candidates are filtered to brokers whose cwd matches the new dispatch target.

Environment

• OS: Linux 6.6 (WSL2 Ubuntu 24.04)
• Codex CLI: codex@openai-codex plugin (current)

Workaround

Downstream detection + kill script: https://github.com/iyo-oyi-128/dotcodex/blob/main/scripts/sweep-codex-orphan-broker.sh
(Reads /proc/PID/cwd and SIGTERMs brokers whose cwd is deleted.)

Refs

• Downstream tracker: https://github.com/iyo-oyi-128/dotcodex/issues/4