bridgemode

BridgeMode

Use the bridgemode MCP tools to enforce a clear workflow instead of free-form shell handoffs.

When to use

• The user wants Claude to stay in control of planning and review.
• The user wants Codex to perform the implementation work.
• The user wants a patch gate before changes touch the real workspace.
• The user wants Claude to monitor Codex progress and intervene if assumptions go wrong.

Workflow

1. Call doctor_environment if command availability is uncertain.
2. Call start_task with the absolute repo path, goal, constraints, and acceptance criteria.
3. Produce the plan in chat.
4. Call submit_plan with the exact approved plan.
5. Call start_codex_task to launch the run in the background.
6. Monitor progress by calling wait_for_codex_update or get_codex_run_update.
7. If the monitoring summary shows a bad assumption or unhelpful trajectory, call restart_codex_task with corrective guidance.
8. Once Codex finishes, inspect the result and, if needed, call get_task_artifact for patch, codex-result, stdout-log, or stderr-log.
9. Review the proposed changes in chat.
10. Call record_review with approved or rejected.
11. Only if approved, call apply_task_changes.

Guardrails

• Always treat the live Claude session as the planner and reviewer.
• Do not apply changes before a review verdict is recorded.
• Prefer start_codex_task plus monitoring over the legacy blocking run_codex_task.
• Poll every 15-30 seconds while Codex is running if the user wants active supervision.
• If you need to steer, use restart_codex_task with a concise correction rather than free-form chat alone.
• If apply_task_changes reports workspace drift, stop and explain the conflicting files instead of forcing an apply.
• If Codex fails, inspect stderr-log and codex-result before retrying.