Codex collaboration policy

Use the Codex MCP server as an independent second model.

This file is authoritative for the shared red lines that are duplicated into research-lit-survey and research-ideation. Changes here must be synchronized to those two files.

Routing

Each skill is self-contained. Loading the one that matches the task is enough.

Shared red lines

• Execution: call Codex MCP tools from the MAIN conversation, never from a Claude subagent. Long calls get backgrounded — do useful work meanwhile.
• Independence: for an independent opinion, always start a FRESH thread. Never send Claude's analysis first. Use codex-reply only after the independent first response has arrived.
• Tool access: Codex has web access and its own tools. Never write "do not run shell commands" or "answer from your own knowledge" into a prompt for a task that needs retrieval — Codex will then report that it did not search, which reflects the prompt's constraints, not its actual access. Require resolvable citations and verify them. The MCP call's own parameters impose the same constraint silently, and this is the easier mistake to make: sandbox: read-only blocks network at the shell layer, workspace-write leaves network_access off by default, and approval-policy: never removes any path to escalate. A retrieval task launched that way is crippled no matter how carefully the prompt is worded, and it usually degrades partially — Codex still answers, from a narrower channel — rather than failing loudly. For any task that must retrieve, pass sandbox: danger-full-access. Treat a Codex report of blocked access as a launch-configuration bug to fix and relaunch; that relaunch is a corrected call, not the one retry allowed under Timeout. Its "I could not find X" is never evidence of absence.
• Deliverable transport: the MCP result returns only Codex's final turn, so a long answer delivered as chat in an earlier turn is silently lost. For anything substantial, instruct Codex to write its deliverable to a named file and reply with just the path. If a result comes back looking like housekeeping, a stray fragment, or an off-topic note, the real work probably exists on disk — go look before concluding it failed or relaunching it.
• Clarification routing: Codex handles its own underspecification by stating assumptions (L1); Claude relays only facts already stated by the user or already measured (L2); ask the user only when the missing information changes the research question, scientific assumptions, or acceptable tradeoffs (L3). Never invent facts or user preferences to satisfy Codex.
• Timeout: slow ≠ failed. On genuine failure retry at most ONCE in a fresh thread; if that fails too, proceed with Claude's own analysis and state explicitly that independent validation was unavailable.
• Disagreement: Claude/Codex disagreements that affect experimental conclusions, result credibility, or direction are key decisions — surface both positions with trade-offs via AskUserQuestion. Do not self-arbitrate.

Elaboration on the above (this file only):

• Subagent Codex calls are never auto-backgrounded, and background processes may be killed by SessionEnd cleanup — hence the main-conversation rule.
• While a long call runs, do useful work in parallel: repo inspection, running tests, organizing hypotheses.
• Restricting Codex's tools is appropriate only when an unaided-reasoning baseline is genuinely the goal, and that intent must be stated explicitly.
• The L1/L2/L3 routing is spelled out in full under Codex clarification policy below.

Experimental design

For nontrivial experiment design, use TWO Codex rounds:

Round 1 (independent design):

1. Claude develops an initial experiment plan independently.
2. In a fresh Codex thread, ask Codex to independently design an experiment from the original problem and constraints only.
3. Compare both plans.

Round 2 (adversarial review):

4. Send Claude's proposed plan to the same Codex thread and ask for an adversarial review focusing on: confounders, leakage, invalid controls, weak baselines, metric mismatch, statistical issues, untested assumptions, alternative explanations, implementation feasibility.
5. Revise the final plan based on valid findings.

Do not merely ask Codex whether the plan "looks good". Evaluate every finding rather than accepting it wholesale; state which findings were accepted, which were rejected, and why.

State the real resource constraints in the prompt (available GPUs, model scales, annotation budget, whether human labeling is possible). A plan that assumes unavailable resources is not a usable plan.

Code implementation

After any nontrivial implementation:

1. Run relevant tests first.
2. Give Codex: the original requirement, relevant repository context, and the resulting diff. Tell Codex it may inspect the repository itself for anything else it needs.
3. Tell Codex to search specifically for: correctness bugs, edge cases, race conditions, state inconsistencies, silent failure, API misuse, numerical issues, resource leaks, unintended behavioral changes, missing tests.
4. Codex acts as a reviewer; it must not assume the implementation is correct. Require concrete findings: location, failure condition, why it is wrong, minimal fix, a test that exposes it.
5. Claude evaluates every Codex finding rather than blindly accepting it. Fix valid issues, then re-run tests.
6. At most ONE Codex review round per implementation; only re-review if the fix changed the design.

Codex clarification policy

When Codex requests additional information, Claude is the FIRST clarification proxy. Never forward questions to the user by default. Route every Codex question through three levels:

Level 1 — Codex handles it itself (preferred): Non-critical underspecification → Codex must state its assumptions explicitly and proceed. Instruct Codex accordingly in the prompt. If Codex asks something answerable from the repository or from the web, do not answer for it: reply telling Codex to inspect the relevant files or search itself, and improve the next handoff prompt to prevent recurrence.

Level 2 — Claude relays existing facts (narrow scope): ONLY when the answer is a fact that already exists in:

• the user's own earlier statements in this conversation
• the original request's explicit constraints
• results Claude has already produced (test output, measurements) Claude relays it verbatim via codex-reply, citing the source ("the user stated earlier that..."). Claude must NOT answer on the user's behalf when the question concerns the user's intent, preferences, priorities, or any scientific judgment — even if Claude believes it can be reasonably inferred. Those are Level 3.

Level 3 — Ask the user (last resort): Only when the missing information materially changes the research question, scientific assumptions, experimental objectives, acceptable tradeoffs, or involves destructive/irreversible decisions. Before asking, digest Codex's questions: present the user with at most 1-2 decision points, each with a one-line explanation of why it affects the scientific conclusion. Relay the answer back to the SAME Codex thread via codex-reply.

Hard rules:

• NEVER invent experimental facts, dataset properties, requirements, or user preferences to satisfy Codex.
• Instruct Codex to avoid interactive elicitation prompts; for long tasks, missing critical input should be returned as a final result containing the open questions (e.g. "STATUS: NEEDS_INPUT" plus a numbered list with why each matters). Treat any unresolved questions in Codex output as needing routing, even if the exact format is not followed.

Per-scenario defaults:

• Experimental design: technical details → Level 1-2; conditions that change scientific validity → Level 3.
• Code review: nearly everything is Level 1-2; do not interrupt the user for information readable from the repo.

(Independence, disagreement routing, and timeout handling are stated once in Shared red lines above and are not repeated here.)