How to Use Claude and Codex Together on a Coding Task

To use Claude and Codex together, give them separate responsibilities, provide the same task instructions, and pass a checked progress record when responsibility changes. Start with one implementing and the other reviewing. You do not need a direct connection between the apps to run that workflow.

fenbs provides a shared place for the task, human decisions, and Where we left off. Each supported assistant can read the same project context rather than relying on a copied conversation that may already be out of date.

What is the simplest workflow to start with?

1. Write one task with a specific behavior to change, an allowed scope, and a way to check the result.
2. Choose one assistant to inspect and implement. Ask the other to wait or perform read-only research on a separate question.
3. Have the implementer record changed files, verification results, unresolved questions, and a proposed next step.
4. Give the reviewer the same task and the current changes. Ask for findings with evidence, without editing files during that review.
5. Resolve findings through one implementer, rerun the relevant checks, and let a person make any remaining approval decision.

For example, suppose a settings screen loses an unsaved display name when a user changes tabs. Ask one assistant to investigate and fix that behavior. Ask the other to review whether the fix preserves the existing save and cancel actions. A concrete question produces a more useful review than “see whether the code looks good.”

Which assistant should plan, implement, or review?

Assign work by the access and task knowledge each session actually has. If Claude is already in the repository with the relevant files open, it may be convenient to implement there and ask Codex to review. You can reverse those responsibilities. Neither model name proves that a session has the necessary tools or understands the task.

Keep the first task small enough to evaluate. Compare the resulting changes and findings against the acceptance checks, the conditions that define a successful result. You can then decide which division of work helps your project rather than treating a general model ranking as a work plan.

Our Claude Code and Codex comparison covers the broader choice of tools. For this workflow, the useful distinction is who may change the files now and who should examine them.

• Planner: identifies the relevant behavior, files, risks, and checks before implementation.
• Implementer: owns a defined set of changes and records what was verified.
• Reviewer: checks the current changes against the task and reports reproducible findings.
• Person responsible: decides scope changes and approves any step that requires their judgment.

What context must both sessions receive?

Give both sessions the goal, relevant project instructions, current human decisions, source locations, and the definition of finished. A reviewer who sees only a diff may miss a requirement. An implementer who sees only an old chat may build an approach the team has already rejected.

Task: Preserve an unsaved display name when switching settings tabs.
Scope: Settings UI only; keep the existing save behavior.
Decision: The owner wants an explicit Save action.
Implementer: Inspect, change the relevant UI, and run focused checks.
Reviewer: Read the current diff; report findings without editing.
Check: Switching tabs preserves the draft; Cancel discards it.
Handoff: Record changed files, checks, uncertainties, and the next action.

Describe unresolved assumptions as questions. If nobody has decided whether a draft should survive a browser reload, do not quietly add that behavior to the task. The implementer can preserve the requested tab behavior while leaving the separate decision visible for a person.

fenbs AI context puts recorded Rules before ordinary project notes, so each assistant can start with the same boundaries. Ask both sessions to state their role after reading it; shared access is useful only when the assistants actually consult the record.

How do you prevent conflicting edits?

For sequential work, let only the current implementer edit the task’s files. Keep the reviewer read-only until the implementation is stable enough to inspect. If the reviewer discovers a problem, have it describe the location, trigger, and effect rather than silently rewriting the implementation while another session is active.

For parallel implementation, use separate working copies and explicitly divide the files or behaviors. A Git worktree is a separate checkout of the same repository. OpenAI’s worktree documentation↗ (opens in a new tab) and Anthropic’s parallel-session guidance↗ (opens in a new tab) explain their supported workflows.

Separate copies prevent accidental overwriting, but they do not make changes automatically compatible. Two assistants can still make incompatible assumptions about an interface. Define the expected inputs and outputs before they start, then assign one person or session to combine and check the final changes.

Do not point a reviewer at a moving target without saying so. Name the revision or stable draft it reviewed, and rerun a focused review if the relevant behavior changes afterward. A review of yesterday’s files does not verify a different implementation today.

What makes the handoff and review useful?

A useful handoff tells the receiver what is known and where to look next. Include current file state, the behavior changed, checks run, and limitations. Keep the code available through your normal authorized repository workflow; a summary does not transport uncommitted files to another computer.

Ask reviewers to connect each finding to the task. For the settings example, a finding might identify the exact action that discards the draft and a short reproduction sequence. A preference for another variable name should not overshadow a missing cancel behavior that the acceptance checks explicitly require.

Anthropic’s Claude Code best practices↗ (opens in a new tab) discusses giving the assistant a way to verify its work. Apply that idea to the combined result: another model agreeing with an explanation does not replace running the relevant check or inspecting the output yourself.

For reusable task instructions, see assistant skills. The separate guide to Claude instructions for Codex owns the file-format question; this workflow depends on both sessions receiving the same approved intent.

How to do this with fenbs

1. Create a free account and add a project and one narrowly scoped coding task.
2. Write the implementation plan and review boundary in the task. Record the person’s decisions separately from the assistants’ proposals.
3. Connect Claude and Codex using their guides on Integrations. MCP, a standard way for an AI app to use an outside tool, lets each read the shared record.
4. Ask the current implementer to save progress before the reviewer starts. Have the reviewer read the context and report findings against the current files.
5. Update the task after resolving findings and save Where we left off. Mark verification honestly, including checks a person still needs to perform.

fenbs does not synchronize two local repositories or automatically send messages between Claude and Codex. If a short task is already going smoothly in one assistant, a second one may add unnecessary review overhead. Use two when separate investigation or review has a clear purpose.

Explore the AI handoff library for other transitions. Your first success should be easy to recognize: one assistant changes the behavior, the other checks it against the agreed task, and the next session can see exactly what remains.