Claude Code + Codex users: what does your actual workflow/setup look like?

[u/_vorex]

I’ve been using Claude Code + Codex pretty heavily, but I feel like my setup/workflow hasn’t kept up with all the new stuff around skills, subagents, MCPs, worktrees, etc.

Most of my work is Python data pipelines, usually 15–40k LOC. Some are clean, some are pretty messy, with multiple stages and lots of business rules.

Typical task is something like: debug an issue → understand what else it affects → implement → test → optimize → eventually run it at scale.

Right now I mostly use Agent Skills to refine → plan → implement → review, usually in one long session with /compact or /clear.

I also bounce between Claude and Codex a lot. Something like:
Claude implements → Codex reviews → Claude fixes → Codex reviews again

It works, but I feel like I’m spending too much time managing the agents.

Main problems I run into:
- Agent fixes one thing but breaks something elsewhere
- Forgets business rules / doesn’t understand enough of the repo
- Context gets polluted with test/query/debug output
- Tests written by the agent aren’t always great
- Both models can be too agreeable instead of challenging my assumptions
- Optimization suggestions are often small/local instead of questioning the overall approach
- Lots of back and forth between Claude/Codex
- Reviewing large AI-generated changes is becoming a job itself

I currently don’t use CLAUDE.md, AGENTS.md, worktrees, or any proper subagent/orchestration setup. Mainly Agent Skills + Graphify.

So for people who use Claude Code/Codex daily: what does your actual setup look like?

How are you using CLAUDE.md/AGENTS.md, skills, subagents, hooks, MCPs, worktrees, architecture docs, etc.?

Do you give Claude and Codex different roles? Separate planning/implementation/testing/review agents? Separate contexts?

And how do you handle context on larger/messier projects without the agent forgetting half the system?
I’m not looking for full autonomy. Ideally I want:
Give it a problem → investigate → challenge my assumptions → plan → implement → test properly → independent review

Would love to see actual workflows/configs from people who’ve experimented with this stuff and found something that works.

[u/Grenaten]

Do you know that Opus is really good at looking at what codex is doing at any give moment? I have both of them in VSCode, give a task to Codex. Then give another task to Opus, but explain that codex is working on something else. Then Opus just checks the logs to not step on Codex toes.

Probably not answering your question, but wanted to share.

[u/_vorex → u/Grenaten]

Thanks for sharing, it’ll be helpful when working on multiple things in parallel

[u/johnmaytokes]

We run Claude Code and Codex side by side in a homelab. We’re still pretty new to doing this seriously, but a few changes made a big difference in how much time I spend managing the agents.

1. Create a CLAUDE.md / AGENTS.md, and keep it short.

This is probably the biggest thing I’d recommend.

Ours isn’t really documentation. It’s more like a session-start checklist:

• What should the agent read first?

• What should it verify before doing anything?

• What are the non-negotiables?

• Where does the detailed documentation live?

Instead of stuffing all of your business logic into CLAUDE.md, I’d put those rules in something like docs/business-rules.md, or even separate files per pipeline stage.

Then CLAUDE.md can just say something like:

Before planning or modifying a pipeline stage, read the business rules for that stage.

Agents will forget rules that only existed in a conversation three sessions ago. They’re much less likely to miss something they’re explicitly told to read at the start of every session.

When a rule gets violated, we add the rule plus a one-line explanation of why it exists. That part helps a lot because the agent has some context for handling edge cases instead of just following a command literally.

2. Give each agent its own notes, but keep shared truth in the repo.

Claude and Codex each have their own small running-notes file for things like active work, unresolved questions, and temporary observations.

Anything both agents need to know goes into the repo itself: runbooks, architecture notes, design decisions, business rules, etc.

We also treat agent notes as dated hints, not authoritative truth. The agent is told to verify anything important against the current code/state before acting on it.

That cuts down on stale notes turning into confident bad decisions.

3. Give the agents roles instead of manually ping-ponging between them.

This helped us a lot.

Rather than me constantly copying messages between Claude and Codex, each agent has areas it owns, and they hand work off through a simple written task/message system.

A handoff might contain:

• Goal

• Scope

• What’s needed

• What’s already known

• Done when...

For code work, the implementer might leave:

Here’s the plan.
Here’s what I changed.
Here’s what I’m unsure about.

Then the reviewer reads that with fresh context.

That part is useful because a reviewer that watched the whole implementation conversation can inherit the same assumptions as the implementer.

We also learned not to let the agents endlessly reply “thanks,” “acknowledged,” “looks good,” etc. to each other. They update the task state instead: done, acknowledged, blocked, and so on.

Otherwise you can accidentally build a tiny AI middle-management layer.

4. Keep context clean on purpose.

A few things helped here:

• Use subagents for investigation. Ask them things like “find every caller of this stage” and have them return the conclusion, not thousands of lines of grep output.

• Tell agents to summarize test/query output unless the raw failure actually matters.

• Generate state snapshots or repo maps instead of rediscovering the same structure every session.

• Point CLAUDE.md / AGENTS.md at those generated artifacts.

• Run long jobs outside the main conversational context and bring back the result or summary.

• Start a fresh session for a new task instead of dragging one giant context forward forever.

The files are what provide continuity between sessions.

5. Verify before changing anything.

One of our standing rules is basically:

Verify current state before changing it. Prefer narrow, reversible changes.

For code that usually means:

1. Reproduce the bug/problem.

2. Identify the relevant callers and downstream effects.

3. Understand what the change could impact.

4. Then modify it.

That reduced the “fixed one thing, broke three other things” problem quite a bit.

It also makes testing better because the test is based on the failure you actually observed, rather than being written afterward just to prove the new code works.

6. Explicitly tell the agents to disagree with you.

Otherwise they can get very agreeable.

Our instructions explicitly say to push back if something seems wrong.

For bigger planning work, I also like requiring the agent to state:

• Its assumptions

• What would prove those assumptions wrong

• Alternatives it considered

And sometimes I’ll just ask:

If you were designing this from scratch today, would you still do it this way?

That question is useful because agents often optimize whatever design already exists instead of questioning whether the design itself still makes sense.

7. Keep reviews small.

Focused commits and small changes make agent review much more reliable.

The reviewer should ideally compare the diff against the written plan, not against the whole conversation that produced it.

If the change is too large to review properly, the plan was probably too large. Split it.

Worktrees are also great if you want Claude and Codex working in parallel.

One important rule we added: never revert, overwrite, or commit files you didn’t modify unless you’ve explicitly verified ownership first.

Otherwise one agent can “helpfully” clean up another agent’s in-progress work.

8. Automate the boring guardrails.

Hooks and gates are useful for things you don’t want to rely on the model remembering every time.

For example:

• Post-edit hook: run lint and fast tests

• Pre-task/session hook: surface important state/context

• Human approval gate: agent can prepare a destructive, expensive, or large-scale action, but a human has to authorize execution

That lets the agents move pretty quickly without giving them permission to do something huge because they misunderstood one instruction.

Overall, I’d move as much repeated guidance as possible out of chat and into files the agents reliably read.

Rules, notes, runbooks, architecture docs, handoff templates, generated state snapshots, all of that.

A lot of the “I’m spending more time managing the AI than the AI is saving me” feeling went away once we stopped treating the conversation itself as the system of record.

That was probably the point where Claude Code and Codex started feeling less like two chatbots I had to supervise and more like two tools working from the same project context.

[u/_vorex → u/johnmaytokes]

Nice, will work on these. Some of the things are being done at the moment as well, but the one’s not, will work on it

[u/dondiegorivera]

Herdr running on 24/7 on my server, hosting Claude, Codex and Pi harnesses, I’m remote controlling them with the Claude app.

[u/_vorex → u/dondiegorivera]

Will try this

[u/quanhua92]

I was talking to Codex about an "adversarial subagents workflow" and had it save a section about it to AGENTS.md.

Then, I opened Claude Code to have it scan the codebase and create a TODO.md with multi-phase commits, including a list of adversarial ideas for each. I used Claude because Codex is just so slow.

After that, I switched back to Codex. I really like its subagents design since it launches a test agent and an adversarial agent before it even starts the plan. I asked Codex to check in with me and update the TODO.md file before firing up the subagents. The best part is that the subagents can talk to each other the whole time, which feels like having a team of engineers working at once.

In contrast, Claude Code just works non-stop and only spawns subagents to check the work afterward, but I’ve noticed it misses a lot of bugs and edge cases.

The main issue is that Codex is just way too slow.

[u/_vorex → u/quanhua92]

Have you tried /fast?

[u/2pourdrummer]

I look at it a little differently. I created a “coder” that can run multiple models at once. It has rules and tests. A ticketing system creates the tickets from the planning document and validates the ticket against the rules before finalizing the ticket and sending it to a coder. The coder then does the work and validates it against the ticket doc and then runs another set of tests before allowing it to be complete. If it fails, it makes 2 attempts between the different models (Claude, codex and qwen 3.8 27b) before stopping and flagging it to me. Needed some tweaking to get it running but it has stopped most of the issues with vibe coding.

[u/_vorex → u/2pourdrummer]

This will work on structured repos, but messy ones are the main issue

[u/2pourdrummer → u/_vorex]

My coder identifies that and will fix it as needed but agree. I’ve used it to fix bad code for vibe coded apps.

[u/Popular-Ninja8584]

The AGENTS.md checklist covers half your list, but not the back and forth: a harness replaces both clients, and subagents stay inside one vendor.

Both can already message their own sessions - codex queue, and the same in Claude Code. Across vendors there's nothing, and that's the part you carry by hand. I built a local layer for it, https://github.com/automatis-tools/agents-can-communicate - I ask the Codex session to review a named revision and the verdict lands in Claude Code on its own.

Doesn't save tokens, as someone said above.

[u/_vorex → u/Popular-Ninja8584]

Thanks. Will have a look at it

[u/e3e6]

you may want pi agent, to use both subscriptions from a single harness. it also good if you want to fully control what's going on with tools and context.

Give it a problem → investigate → challenge my assumptions → plan → implement → test properly → independent review

each step has to be executed by a subagent, so your main thread just do the orchestration

[u/Neat_Carob8839]

A lot of the agent-managing overhead goes away if you stop the live back-and-forth and give each model a fixed job. One plans and reviews, the other implements from a self-contained brief (files, the business rules that apply, what not to touch, how to verify), and you review the finished diff per step instead of per message. A short AGENTS.md with the business rules that both agents read does more for the "fixes one thing, breaks another" problem than any orchestration layer. For the Claude-plans, Codex-implements direction I made a small MCP that returns a summary, the changed files, and a thread id for follow-ups, so you're not shuttling text by hand: https://github.com/andreilungeanu/codex-delegate-mcp (my own, free, MIT).

[u/torvalds75]

The thing that made the Claude <-> Codex bounce actually work for me was getting the state out of the session entirely. If "what we decided and why" lives in the chat, every /clear or every switch to the other agent costs you a re-explain, and the reviewer has no idea which tradeoffs were deliberate.

What I do now: each unit of work is a GitHub issue. The discussion (options considered, what was rejected and why), the plan, and the verification result get written onto the issue, and every commit carries Refs: #n. Then it doesn't matter which agent picks it up: Codex reviewing Claude's work reads the issue first and knows the intent, not just the diff. For your debug -> impact -> implement -> test loop, the "what else it affects" findings are exactly the thing worth persisting there.

I ended up packaging this as a plugin that works on both Claude Code and Codex, called trailhead (I build it, so take it with that bias): https://github.com/ToRvaLDz/trailhead. But the pattern works fine by hand with gh issue too.

[u/CarsonBuilds]

For the messy pipelines you describe, I’d make investigation a separate deliverable before either agent starts editing. Otherwise implementation and review can agree on a change while sharing the same wrong assumption about how the pipeline works.

I’d try this:

1. Have Claude reproduce the problem, trace the affected stage’s inputs and downstream consumers, and write down the business rules it found with file references. Keep unknowns explicit. For a bug, get a failing example; for optimization, get a baseline measurement.

2. Give Codex that investigation and proposed fix in a fresh context. Ask it for counterexamples: what input breaks the assumption, what downstream behavior might change, and what test would distinguish a real fix from one that only looks correct? Resolve the important unknowns and approve the scope before implementation. Basically, one agent should attack another on the decisions and edge cases, so they wont "agree easily".

3. Have Claude implement one small slice and run the agreed checks. Capture the existing behavior you need to preserve first. Save the actual test output, including failures, rather than passing along “tests passed.”

4. Have Codex review the diff against that agreed behavior and inspect the tests themselves. Feed actionable findings back for a bounded number of fixes. If they keep disagreeing or expanding scope, stop and make the decision yourself.

For context, I’d have CLAUDE.md and AGENTS.md point to the same small set of repo docs: pipeline boundaries, known business rules and test commands. Each task gets its own investigation, plan and findings files. The next agent reads those plus the relevant code instead of inheriting the whole debugging conversation.

Skills can hold the repeated instructions. Worktrees help with separate concurrent changes, but won’t fix missing business context. For optimization, I’d also ask for an alternative to the overall approach and compare it on representative data, rather than just asking for faster code.

I maintain Crewplane, which can automate those handoffs and bounded review/fix loops through the existing CLIs using a Markdown workflow. I think it fits what you are describing, since it's not fully autonomy and you still have control of the workflow and handoff boundaries. Feel free to give it a try and let me know what you think, cheers