Investigate and prove concurrent-checkout worktree guidance

[shiny-code-bot]

Context

We observed a session continue in a shared dirty checkout even though the active-session warning existed. The warning was already injected into the model request, but the wording allowed the agent to silently stay in the checkout instead of making an explicit choice.

PR #301 tightened the model-facing notice so the agent must either create/switch to an isolated worktree before edits or explicitly state why it is staying. It also added a request-capture regression test proving the notice is sent as a developer message before the user task.

Remaining Work

• Reproduce the flow in the exec/TUI harness with an active session, a dirty checkout, and an implementation request.
• Verify the transcript shows the agent either creates/switches to a worktree or explains why it is staying before the first file edit.
• Check resume, compaction, and follow-up-turn paths so the notice reaches every model request that can edit files.
• Observe local rollout/session logs for stale active-session records, wrong-session warnings, or missing notice injection.
• Decide whether Every Code should add stronger product behavior, such as auto-offering an isolated worktree or requiring an explicit override when a dirty checkout is shared.
• Add telemetry or log assertions that make notice delivery and the visible worktree choice easy to prove later.
• Ensure stale or expired active-session records do not cause noisy over-warning.

Acceptance Criteria

• A deterministic exec/TUI harness test or reproduction script covers the concurrent-checkout implementation flow.
• Before any file edit, the agent visibly chooses an isolated worktree or gives an explicit reason for staying in the checkout.
• The proof covers at least the normal first-turn path and one resume/follow-up path.
• The issue links any rollout/log evidence found during investigation.

[shiny-code-bot]

Additional constraints from dogfooding in cbusillo/codex-skills:

• Suggested canonical task-worktree root: $CODE_HOME/worktrees/<repo-name>/<branch-or-task>.
• Do not silently move every concurrent session into a worktree. Some sessions are read-only/exploratory, and even implementation work may need the original checkout's local setup.
• The harness should create a visible choice point before edits when another write-capable session is active:
  • use/create the suggested isolated worktree, or
  • explicitly acknowledge staying in the shared checkout with a reason.
• The choice UI/model notice should mention the practical tradeoff: linked worktrees do not automatically carry local setup such as virtualenvs, node_modules, ignored .env files, or other checkout-local secrets/config.
• The current PR fix(core): require visible worktree choice #301 wording is better but still too soft in practice: an agent in codex-skills missed the warning, edited in the shared checkout, then had to stash and move work into an isolated worktree after branch/session drift was noticed.

Related repo-side tracking: cbusillo/codex-skills#272.