Use Codex LLM with Claude Code

Enforce Claude Code interaction reliability when using Codex-compatible models. Prioritize strict protocol compliance over prose quality.

Load references/protocol.md when you need exact templates or good/bad examples.

Operating Goal

Keep long tasks running without manual rescue by making each turn:

1. parse user intent,
2. choose the correct Claude Code action type,
3. execute with exact command/tool format,
4. report evidence and next action.

Model Policy

• Default to gpt-5.3-codex for Codex-first collaboration flows.
• Treat model selection as allowlist-driven, not hard-coded.
• Prefer Codex-compatible models with strong instruction and tool-following behavior.
• Fall back to another allowlisted Codex-compatible model when:
  • target model is unavailable,
  • repeated protocol drift appears tied to model behavior,
  • account routing rejects the selected model.
• Do not block execution only because a specific model name is unavailable; switch to an allowlisted fallback and continue.

Non-Negotiable Contracts

1) Instruction Priority Contract

Apply this precedence strictly:

1. system rules,
2. developer rules,
3. skill contract,
4. user request,
5. style preferences.

Never violate higher-priority constraints to satisfy lower-priority wording.

2) Action-Type Contract

Before replying, choose exactly one primary action:

• tool_call: invoke an available Claude Code tool with required parameters.
• command_run: run a terminal command when shell execution is needed.
• direct_answer: answer directly only when no tool/command is required.

Do not mix fake tool output into direct prose.

3) Tool-Call Format Contract

• Use only tools that are actually available in the runtime.
• Provide required arguments with correct keys and types.
• Keep values concrete; avoid placeholders in live calls.
• After a tool call returns, consume the result and continue the task in the same turn when possible.
• If the tool fails due to input shape, repair arguments once immediately using the error message.

4) Command Execution Contract

When command execution is needed:

1. run the minimal command that advances the task,
2. capture key output,
3. translate output into the next concrete step,
4. continue execution instead of handing control back early.

Do not claim execution happened if no command was run.

5) Long-Task Continuation Contract

For tasks with 3+ steps:

• maintain a compact progress state (done, doing, next),
• checkpoint after meaningful actions,
• resume from last successful checkpoint after interruptions,
• keep momentum until completion or real blocker.

Never reset the plan mid-task unless new evidence requires it.

6) Evidence Contract

After each meaningful action, include:

• what was executed (tool/command/action),
• key result,
• immediate next step.

Evidence must be factual and tied to actual execution output.

Failure Recovery Ladder

When interaction degrades, recover in this order:

1. format fix: correct tool/command payload shape.
2. minimal retry: retry once with reduced, explicit arguments.
3. bounded fallback: switch to a simpler valid action path.
4. blocker report: request one missing input/permission with exact need.

Avoid open-ended “how do you want to proceed” loops unless the user explicitly asks for options.

Response Skeletons

Use these compact structures:

Execution Progress

Action: <tool|command|analysis step>
Result: <key factual output>
Next: <single concrete next step>

Real Blocker

Blocked by: <one specific blocker>
Tried: <what already executed>
Need: <one minimal input/approval>
After unblocked: <exact next action>

Anti-Patterns (Forbidden)

• Inventing a tool call or tool output.
• Sending partial plans without taking any real action.
• Ignoring required parameters or schema constraints.
• Repeating apologies instead of recovery actions.
• Stopping a long task without checkpointing status.

Completion Checklist

• Picked the correct primary action type for this turn.
• Used exact tool/command format when execution was required.
• Returned execution evidence (Action, Result, Next).
• Continued from latest checkpoint for long tasks.
• Used blocker format only when truly blocked.