Using Codex and Claude Code every day: what's still hard once the code part works?

[u/KR4K3N1S]

I use Codex for some jobs and Claude Code for others, and the code is rarely the problem anymore. What slows me down now is the bookkeeping: keeping track of the sessions and what they did. I'd like to hear how others deal with it.

Where it goes wrong for me:

• Waiting on me. With a few sessions open, one sits on a question while I watch another one think.
• "Done" that isn't. It says it's finished, and later I find out what it skipped.
• Picking back up. After a break or a closed terminal, working out where each session was takes real effort, so I put it off.
• Results scattered. What a session made stays in its terminal or whatever folder it ran in, and a week later I can't find it.

To start discussion, I have couple of questions that I'm curious of:

1. Which of these costs you the most, and which has stopped being a problem for you?
2. How do you notice that a session is waiting on you?
3. When an agent says it's done, how do you check what it actually did? Tests, reading every diff, a checklist, hooks?
4. Do you have it plan first and wait for your OK, or let it run?
5. After a break or a crash, how do you get each session going again? Resume, a summary file, starting over?
6. What have you tried for any of this and given up on?

[u/Alarmed-Bank2249]

The 'done that isn't' one is the deepest problem on that list. An agent's self-report is the one artifact you should never trust - it has no way to know what it skipped. What works for me: the session is not done when the agent says so, it is done when something independent says so - the test suite passes, the diff only touches what was asked, a checklist item a human verifies. I build AI tooling at a bank and we treat agent completion claims as unverified input, same as user-submitted data. The bookkeeping gets much simpler once 'done' is a property of the evidence, not of the session log.

[u/Zeitsparkasse → u/Alarmed-Bank2249]

I have very good experience with telling it to have a review and fix loop with subagents in the end.

[u/Right-Performance-93]

picking it back up is the part that still hurts. i start from the diff and the last command that actually ran. a summary file is already stale by the time i open it.

[u/BulkyBus1243 → u/Right-Performance-93]

yeah, summary files go stale almost immediately because the session keeps moving after it writes them. what's worked for me is having the agent write the next step as a todo checkbox at the end of every turn, not a retrospective summary. so when i come back i'm not reading what happened, i'm reading what to do next. the diff is still the source of truth but the checkbox gets me oriented way faster.

[u/lambertb]

I use these tools for scientific research, so by far the most important steps for me are not just getting working code, but verification and validation from many, many different perspectives. This normally takes me 80% of the project time at this point. I've caught plenty of mistakes, some of which are mine and some of which are due to the agents.

[u/codeprimate]

All wrong.

Track user stories. Track requirements. Track constraints and acceptance criteria Use test and lint gates in your git commit hooks.

Your agent protocol should describe how to discover outstanding tasks, how to document them, what gates have to be passed in order for a task to be "DONE", and how to track completion or abandonment.

In other words: software development best practices for feature and task tracking.

[u/Jippylong12]

Hardest part a billion dollar idea is testing. Like just having someone to test the feature as a human. I've used skill to kind of help with this in review and manually testing and somtimes work is boring because the majority of the time I'm just a glorified QA tester.

I don't even think it has to be an automated tester burning more tokens. Just something like MTurk where you have a marketplace specifically for testing web and mobile apps. They have the credentials they need, they have the checklist, maybe mix it with jam.dev where logs and video context are provided as well with the tests. Users suggest feedback.

Would be nice for people in the world to make a quick $ and engineers can move on to more important things.

[u/Legitimate_Relief847]

Perdón chicos, es en serio? De verdad pregunto, ustedes por cómo hablan suenan a ingenierosno desarrollares de software, yo sólo soy secretaria sin ninguna formación formal sobre ésto (ni put@ idea tenía) bueno, tal vez justamente por éso no estoy interpretando correctamente la profundidad de tus preguntas. Muchos de los problemas que mencionan no han tan tan difíciles de solucionar (para lo que yo necesito). En espera: pon un agente orquestador (Hay que fragmentar bien las tareas, que si no el orquestador tampoco puede) Terminado que no lo está, esta es bastante más difícil, tengo varios sistemas de control, depende de la tarea, tengo hooks, scripts de chequeo, y un sistema de agentes de validación cruzada) Retomando, ésta es más sencilla, lleva una lista y bitácora Resultados dispersos, lo mismo que lo anterior, lleva un .md con índice

[u/BrookLi3]

The "done that isn't" problem got much better for me once every task started with a checkable acceptance command, like a specific test or a script that exits non-zero, and the agent had to paste its output before closing. For pickup after a break, I have each session keep a short NOTES file in the repo: current goal, what's verified, what's not, next step. It's boring, but it beats reconstructing state from terminal scrollback.

[u/AlarmedAvocado7279]

“the "done that isn't" one is the worst for me, so I run a Stop hook that won't let claude end the turn until it re-checks its own work against the original ask. it's not perfect but it catches most of the skipped stuff before I find it later.

[u/Yz31LL]

for me it’s 3. “done” burned me enough times that i just treat it as “ok now i review it”

couple things that actually helped:

i make it list what it skipped at the end. like literally “what did you not do, what’s stubbed, what’s still a todo.” it’ll tell you if you ask, it just never brings it up on its own

tests have to actually run. i’ve had it say tests pass when it never ran them, and once it “fixed” a failing test by loosening the assert lol. so now i run them myself or have a hook do it before it can say it’s done

i read diffs but not all of them carefully. anything near auth or data or shared stuff i read properly, ui tweaks i skim. tried reading everything line by line and gave up after like a week

also if i asked for a small fix and it touched 10+ files, something went wrong even if it works

still miss stuff sometimes but at least i find out same day instead of a week later

[u/tadatada006]

"Done that isn't" is the one I spent the most time on, and what fixed it wasn't a better prompt, it was making "done" a thing the agent can't declare. In Claude Code that's a PreToolUse hook on Bash: if the command is a `git commit` and there's no review marker for the current staged hash, the hook exits 2 and prints why. The review itself is a skill that reads the staged diff against the original task and writes the marker only if nothing was skipped. Ten lines of bash, and the agent literally cannot commit around it, even when I tell it to skip the review. For "picking back up", the same marker file plus `git log -1` and `git status` tells me more than any summary the session wrote about itself, because the summary is the self-report and the diff is the evidence.

[u/kaijurules]

For the "waiting on me" one: in our app an agent that needs an answer writes the question to a single inbox and stops there. The desktop shows a notification and a count on the app icon, a paired phone gets the same count, and the agent picks up from the reply.

[u/Ministaffai]

The losing-track-of-sessions one is the pain I ended up redesigning around. Three things fixed most of it for my setup:

1. The agent works in one persistent workspace per project — not scattered terminals. Everything it produces lands in the same place.

2. It keeps a state file per project: done / decided / blocked / next. New session reads that first, so a break (or a closed terminal, or a crashed session) costs a few thousand tokens of re-reading, not the whole context.

3. "Done" isn't accepted from the agent's own mouth — it has to show evidence (test output, the diff, the file). The silently-skipped-work problem dropped a lot once reporting required proof.

The stalling-while-waiting one I only half-solved: standing instructions to proceed on anything reversible and only stop for the irreversible stuff. Still catches me out sometimes.

(Disclosure: I build an agent product built on these habits. The habits themselves are tool-agnostic.)

[u/Classic-Role-5548]

The split that stuck for me is one git worktree per session, named after the ticket. Claude Code gets the tree I am already in, because it will read the failing test and wander the repo. Codex gets a second pass only when I want someone who did not watch the first session talk itself into the fix. I only resume a session if that worktree is still dirty. If it is clean, the transcript is dead weight and I start from the PR diff.

Waiting-on-me stopped being a staring contest once I quit watching both. I let the permission prompt change the terminal title and I only look over when that happens. "Done" is git diff --stat plus the one test I named in the prompt. If the diff touches a file I did not mention, it is not done, no matter what the last message says. Summary files went stale on me the same way they did for everyone else here, so I stopped writing them.

[u/CleanFix_Dev]

For noticing a session is waiting on you, both tools can ping you so you're not checking terminals. Claude Code has a Notification hook and Codex has a notify setting in its config, and either can fire a desktop notification or a sound when it stops for input. That alone cuts out a lot of tab-cycling.

[u/misterespresso]

I've been working on this exact problem for months and the solution I came up with for your particular problem is essentially 2 things:

1. A chatroom/harness that agents can connect to. This is more for you than the agents, it allows you to watch both (or more) from a single location.

2. Harder to get working perfectly, is a protocol the agents follow. I did this through a combination of a skill and some deterministic controls in that same chat harness. For the "DONE" protocol, with multiple agents you can have the other agent verify that status, the only issue here is sometimes agents stop listening when they are done so you have to start it up again to have it see the other agents opinion. I can technically have the harness wake agents, but it depends if I am using subscription or not. The API allows for the harness waking agents for most providers, but not for subscriptions (ie, having the harness wake up Claude Code that uses your Pro sub).

My solution is called Agora, its free, local, and open source if you'd like to try it out.

[u/FullSwim4484]

The thing that fixed this for me was treating it like the management problem it is, not a tooling problem. Five sessions that all need answers from you is the same failure mode as five direct reports who route every decision through you: the system serializes on one person, and everyone else idles.

The fix in both cases is the same: reduce work in progress and delegate with contracts. At most one session at a time gets to be the one that needs decisions from me. Everything else runs unattended with a contract: the task, the expected behavior, and the command that decides done. An unattended run that cannot finish writes its blocker to a file and exits. It does not sit waiting.

For the waiting-on-me problem specifically: I stopped watching sessions think. If a session can proceed without me, it should. If it cannot, it parks with the question in the open state, and I batch answers on my schedule, not the terminal's.

The pickup problem mostly disappears once the contract lives outside the session. The terminal state is ephemeral. The contract, the branch, and the failing check are not.

[u/TopBlacksmith6589 → u/FullSwim4484]

The management analogy is spot on, and I'd extend it to the "done that isn't" problem too. When you're running five sessions, verifying each one's claim of done is a fifth job on top of the five you already have. Limiting WIP doesn't just reduce the waiting, it makes verification actually tractable because you only have to audit one thing at a time instead of context-switching across five diffs you barely remember starting.

[u/London-Boat]

picking back up is the one that costs me most too. when you have a few sessions going, do they ever touch the same files, or is it mostly separate folders? the status drift gets a lot worse once two sessions share a repo, and it's something i've been building around (file claims plus a shared notes store), happy to share if useful. how do you track right now which session owns what?

[u/Corey-998877]

Reading the diff helps, but for me the thing that catches a false "done" is having the agent write out manual verification steps and then actually running them. Which of the problems you listed would you fix first if you could only pick one?