Interactive Issue Execution Worktree Guardrails

---
name: interactive-issue-execution-worktree-guardrails
description: Execute approved GitHub issues in isolated worktrees with interactive Codex/Codex runs, while containing agent drift and salvaging progress when provider/runtime problems occur.
triggers:
  - User asks to implement GitHub issue work via tmux or interactive Codex
  - Multiple provider lanes are being run in parallel across issue clusters
  - Main checkout is dirty, behind remote, or otherwise unsafe for direct execution
  - Autonomous agent drift or provider quota failures threaten a run
---

# Interactive issue execution worktree guardrails

Use this for approved issue execution waves in `workspace-hub`-style repos when the user wants tmux/interactive Codex and/or parallel provider dispatch.

## Core pattern
1. Start from a clean isolation boundary.
   - `git fetch origin`
   - create a dedicated worktree per issue or tightly bounded issue cluster
   - base from `origin/main`
   - do not use the dirty main checkout for implementation
2. Materialize plan approval locally.
   - if the issue is approved by user direction or GitHub label but local `.planning/plan-approved/<issue>.md` is missing, add the approval marker inside the worktree and commit it first
3. Write a prompt file in the worktree.
   - keep the mission bounded
   - list owned paths and forbidden paths explicitly
   - require final validation, commit, push, issue comment, and close when complete
4. Launch the provider in an isolated lane.
   - Codex: use tmux + interactive `Codex --dangerously-skip-permissions` when explicitly approved by the user
   - Codex: use autonomous `codex exec --dangerously-bypass-approvals-and-sandbox` for bounded doc/report/readiness tasks
   - Gemini: treat as opportunistic; expect quota failures and have fallback lanes ready
5. Monitor and intervene early.
   - capture pane / inspect status frequently
   - if the agent touches forbidden files, revert those files externally immediately and restate scope in the session
6. Salvage instead of restarting from zero.
   - if Codex stalls or drifts repeatedly, switch to deterministic local generation (`execute_code`, focused scripts, or another provider) to finish the bounded deliverable
   - preserve useful artifacts, remove temporary prompt files, then validate and land
7. Rebase before push.
   - multiple parallel lanes move `main`; expect `fetch` + `rebase origin/main` before pushing
8. Close only after verification.
   - confirm landed commit, owned-file-only diff, issue comment with commit hash/artifacts, and issue closure where scope is fully implemented

## Prompt design rules
Include these sections explicitly:
- repo/worktree/branch/issue number
- mission in one sentence
- owned paths
- read-only context paths
- forbidden paths
- required deliverables
- validation minimum
- instruction to remove temporary prompt artifacts before final commit if they are not durable deliverables

## Known failure modes and mitigations

### 1) Codex drifts into unrelated files
Observed recurring hazard: `scripts/testing/coverage-results.json` was repeatedly modified during unrelated issue work.

Mitigation:
- declare forbidden paths in the prompt
- monitor early output, not just the final result
- if drift occurs, externally revert the file immediately
- send a corrective instruction in tmux constraining the scope to owned paths only
- verify `git status` before commit shows only expected files

### 2) Provider quota exhaustion
Observed:
- Gemini lanes can fail with HTTP 429 or credit exhaustion
- parallel waves can leave one provider unusable mid-run

Mitigation:
- do not block the whole wave on one provider
- keep a fallback Codex or Codex lane ready for planning/readiness/doc generation
- comment on the issue if a provider-specific run fails so the execution trail remains visible

### 3) Worktree hook / pre-push environment drift
Observed: valid doc-only changes can fail pre-push due to unrelated repo hook environment issues.

Mitigation:
- validate the actual scope independently
- if the failure is clearly unrelated and the user has authorized aggressive execution, `--no-verify` may be acceptable for low-risk doc/report changes
- document that choice in the issue comment

### 3b) Plan-approved worktree still blocks late commits for ignored `.Codex/*` runtime paths
Observed in `feat/ecosystem-sync` execution:
- `.planning/plan-approved/<issue>.md` existed locally and was committed
- normal code/test commits passed
- a later commit that added `.Codex/cron/...` and `.Codex/state/...` files required `git add -f` because those paths were ignored
- the subsequent commit was blocked by the plan gate with `NO APPROVAL` despite the existing marker

Mitigation:
- before starting work that must land files under ignored/runtime directories (especially `.Codex/cron/`, `.Codex/state/`, other force-added paths), probe repo policy early rather than discovering it at the final commit
- explicitly check both:
  - whether `.gitignore` ignores the intended deliverable path
  - whether the local enforcement hooks treat those paths as implementation requiring a different approval route
- if the path requires `git add -f`, treat that as a risk signal and do a small preflight commit experiment or hook inspection before spending a full execution wave on dependent tasks
- when the hook blocks, stop and escalate; do not use `FORCE_PLAN_GATE=1`, `--no-verify`, or similar bypasses unless the user explicitly authorizes that exact bypass
- preserve the staged tree and report the exact blocked paths, hook message, and marker-file evidence so the user can resolve policy vs plan mismatch quickly

### 4) Agent run becomes unproductive
Mitigation:
- stop the session instead of letting it burn budget
- switch to a deterministic local method (`execute_code`) for machine-generated artifacts such as inventories, manifests, and validation reports
- use the agent again only for review/final polish if needed

### 5) Repo-local wrappers and audit scripts break in worktrees due to inherited environment
Observed:
- repo-local wrappers that trust inherited `WORKSPACE_HUB` can accidentally execute against the dirty main checkout instead of the isolated worktree
- direct/manual script runs can also mis-read config or policy files from the wrong checkout when `WORKSPACE_HUB` points elsewhere

Mitigation:
- for repo-local wrappers, derive repo root from the wrapper/script path (`BASH_SOURCE` / `__file__`) instead of trusting inherited `WORKSPACE_HUB`
- treat environment variables like `WORKSPACE_HUB` as optional overrides only when that is explicitly intended and tested
- add a wrapper test that sets a stale `WORKSPACE_HUB` and verifies dry-run output still points at the worktree-local script path
- when validating a new deterministic script in a worktree, test both:
  - normal dry-run/runtime
  - stale-env dry-run/runtime

### 6) Baseline/delta artifact identity churn hides real changes
Observed in deterministic weekly audit work:
- using absolute checkout/worktree paths in `audit_scope` makes baseline reuse fail across worktrees
- including volatile path lists inside the finding identity key causes path-footprint changes to look like brand-new findings instead of `is_changed`
- carry-forward sections can silently omit unchanged lower-confidence findings unless explicitly reconciled into the markdown/report totals

Mitigation:
- derive a stable audit scope from repo-relative semantics when possible (for example `.Codex/skills`) rather than absolute worktree paths
- define finding identity from semantic fields that should survive normal location churn (classification + canonical names), not from volatile path lists
- detect path/canonical-name/classification changes in delta comparison so scope changes are surfaced as changed findings
- ensure carry-forward markdown/report sections reconcile with summary counts, including unchanged non-high-confidence findings that remain active
- if `_core` / `_internal` findings are meant to be informational-only, propagate that flag through every finding path (including leaf-collision findings), not just duplicate-name findings

### 7) Approved issue scope is stale relative to current main / current CI
Observed in worldenergydata #2451 execution:
- the approved issue was based on an earlier failing CI run with three clustered signatures
- on a fresh worktree from current `origin/main`, one planned cluster (benchmark fixture/plugin failure) no longer reproduced when tested under CI-like extras
- two other signatures were still real and worth fixing, but the broader directory still had unrelated pre-existing failures
- PR CI stayed red overall even after the bounded fix, so closure had to rely on proving the original signatures disappeared rather than waiting for a fully green repo

Mitigation:
- before editing, rerun a verification-first precheck on current `origin/main` in the isolated worktree and mirror CI conditions as closely as practical (`--all-extras`, issue-specific test targets, log inspection)
- treat the issue body/old CI run as a hypothesis, not ground truth; narrow scope to the failures that still reproduce on current head
- if a planned cluster no longer reproduces, do not force a speculative fix just to match the old plan; document the non-reproduction and keep the patch bounded to live failures
- when adjacent failures appear outside the approved cluster, open explicit follow-up issues instead of silently absorbing them into the execution issue
- if PR CI remains red for unrelated repo debt, grep the matrix logs for the original signatures and record evidence that those signatures are gone across all relevant jobs
- only declare the issue materially complete when the approved failure signatures are removed or intentionally converted into tracked skips, even if unrelated checks still fail

### 8) Background `Codex -p` worktree runs can implement successfully but still be blocked from validation/commenting by repo-local allowlists
Observed in worldenergydata cost-wave execution (#335/#338/#337):
- delegated/subagent launch was not reliable for the parallel wave, so execution switched to direct background `Codex -p` runs in isolated worktrees
- Codex finished the code changes, but the repo-local `.Codex/settings.json` allowlist blocked commands like `uv run`, `python -m pytest`, `pytest`, and `gh issue comment`
- the worker logs asked for approval to run those commands even though the implementation itself had completed
- closeout still succeeded by running validation and GitHub comments centrally from Hermes after inspecting the worktree diff and worker log

Mitigation:
- for parallel worktree waves, treat background `Codex -p` as an implementation engine, not necessarily the authority for final validation or GitHub reporting
- after each worker exits, inspect three things before trusting the run:
  - `git status --short` / changed files in the worktree
  - the worker log for any approval-blocked commands
  - targeted tests run centrally from Hermes in the same worktree
- if the worker was blocked on `pytest`, `uv run`, or `gh`, do not rerun the whole agent immediately; keep the produced diff, validate it centrally, then commit/push/comment from Hermes
- post an issue note when execution ownership changes (for example: delegated worker timed out, switching to direct background Codex; worker could not comment, so closeout was posted centrally)
- verify pre-existing regression blockers explicitly instead of treating them as worker failures; in this run a planned regression target referenced a module absent on current main, so the right outcome was: document blocker, prove it is pre-existing, and keep the issue-scoped patch bounded
- if this allowlist pattern is expected in a repo, prefer a two-layer plan from the start:
  - worker owns code/test-writing inside the isolated worktree
  - Hermes owns final validation, commit/push, and GitHub comments unless the repo settings explicitly allow those commands

### 8b) Parallel approved worktrees can still produce later PR merge conflicts through shared export/barrel files
Observed in worldenergydata cost-wave landing:
- #335, #337, and #338 were executed in separate worktrees and validated independently
- after #335 merged first, #337 became `DIRTY` at PR level because both branches modified `src/worldenergydata/cost/data_collection/__init__.py`
- the original execution wave had serialized #337 after #335 for implementation ownership, but the later PR-merge step still required an explicit rebase onto updated `origin/main`
- resolving the conflict correctly required preserving both surfaces in the barrel/export file, then rerunning a combined targeted suite (`test_disclosure_ingest_contract.py`, `test_linkage.py`, `test_calibration_schema.py`) before force-pushing the rebased branch

Mitigation:
- when parallel/semi-parallel issue branches touch the same package export file, `__init__.py`, registry file, or shared manifest, assume the merge stage may still serialize even if implementation work was isolated
- before merging the second/third PR in a wave, inspect `gh pr view <n> --json mergeStateStatus` and be ready to rebase the branch onto current `origin/main`
- resolve shared export conflicts by composing both validated surfaces, not by picking one side mechanically
- after rebase conflict resolution, rerun a combined targeted validation set that covers:
  - the branch's own new tests
  - the already-merged adjacent boundary tests touched by the shared file
- if the rebased branch was already pushed, use `git push --force-with-lease` and document that the force-push was only to land the conflict-resolved, revalidated branch
- treat PR mergeability as a separate verification gate from worktree-local implementation success

## Verification checklist
- `git status --short` contains only owned files
- no forbidden files remain modified
- temp prompt files are removed unless intentionally part of the deliverable
- outputs numerically reconcile with their authoritative ledgers or sources
- worktree branch rebased onto latest `origin/main`
- push succeeded (or exception documented)
- issue comment includes what landed and the commit hash
- issue closed only if implementation, not planning-only artifacts, actually completed the approved scope

## When to keep issue open
Keep the issue open if the run only produced readiness dossiers, planning artifacts, or partial reconnaissance without the approved implementation landing.

## Good fit
- bounded doc/report reconciliation
- metadata-only sweeps
- readiness dossiers
- governance or portability doc changes

## Bad fit
- large code changes without tests
- issues lacking approval
- mixed-scope waves without clear owned paths