My Codex App Workflow: Triage, Fix Threads, and Just Enough Research

There are two bad defaults when you start doing real work with a coding agent.

The first is one giant thread where everything happens forever. Ideas, debugging, random notes, half-formed plans, implementation, follow-up fixes. It feels convenient right up until the thread turns into soup and you cannot remember where a decision was made or which bit of context still matters.

The second is going full command-center mode with elaborate agent choreography for every piece of work. Parallel researchers, planners, implementers, reviewers, all passing notes to each other like you are running a tiny software consultancy inside your terminal. That can be impressive. It can also be a very efficient way to burn time and attention on process that does not actually help.

What I have settled into with the Codex app is a middle path: one mostly long-lived Triage thread, one focused Fix issue-XXX thread for each piece of implementation work, and occasional Research XX threads when I genuinely need to go learn something first.

It is not fancy. That is exactly why it works.

The problem with giant threads

Long threads decay. Not immediately, but predictably.

At the start, a single thread feels efficient because everything is “right there”. After a while it becomes a junk drawer. A bug report sits next to a design question, which sits next to a shell transcript, which sits next to a half-baked idea you had at midnight. The agent can still technically see all of it, but that does not mean the context is useful.

What I care about in day-to-day use is not maximum theoretical continuity. I care about keeping the current task legible. I want the thread title to tell me what I am doing. I want the history to be easy to skim later. And I want the working context to stay small enough that the app remains fast and pleasant.

That means I do not want one immortal everything-thread.

The Triage thread as the inbox

The one long-lived exception is Triage.

That thread is my inbox. It is where I dump observations, rough ideas, “this seems off” notes, and small bits of investigation that are not yet implementation work. If I notice a bug while doing something else, it goes there. If I want to capture an idea for a post or a refactor without acting on it immediately, it goes there too.

This has effectively replaced the old /btw habit I had in Claude Code. The point is the same: capture now, sort later. The difference is that in the Codex app I like having a dedicated thread that stays open and accumulates that intake work over time.

The important thing is that Triage is not where I finish work. It is where I decide what the work is.

GitHub Issues sits in the middle

From Triage, I file actual tasks into GitHub Issues, or any similar issue tracker an agent can handle cleanly.

That is the durable ledger. Threads are great for active conversation and local context. They are not where I want my task list to live. I want a real issue tracker that I can search, sort, sync, and return to later without mentally reconstructing a conversation.

So the flow is simple:

1. Something comes up in Triage.
2. If it is real work, I file a GitHub issue.
3. The issue becomes the handoff point from vague thought to concrete task.

That separation matters. It keeps the thread free to be conversational, while the issue tracker stays authoritative about what exists, what is in progress, and what still needs doing.

One Fix issue-XXX thread per implementation task

Once I actually start working an issue, I spin up a separate thread named something like Fix issue-2od.

This is probably the single habit that improved the experience the most.

Instead of dragging a whole triage history behind me, I get a clean workspace focused on one job. The thread name is searchable. The history is about one thing. If I need to come back in a week, I do not have to decode whether a command or explanation was related to this issue or some other thing that happened nearby.

This also makes the agent feel better to use. Keeping the active context narrow tends to keep responses snappier and the conversation more relevant. I do not need the model to remember every adjacent concern I had this month. I need it to help me finish the thing in front of me.

Thread naming is part of the system here, not an afterthought. If I can scan the sidebar and immediately see Triage, Fix issue-2od, Fix issue-31a, and Research Zola feeds, I have already reduced a bunch of cognitive load before opening anything.

Research XX threads are for uncertainty, not theater

I do sometimes open separate research threads, but only when the task is genuinely exploratory.

If I need to understand a library, compare approaches, or verify how something works before I decide what to implement, that gets a Research XX thread. The key is that research is its own mode. It has a different shape than implementation, and I would rather keep that separate than dilute a fix thread with a bunch of speculative branching.

These research threads often end the same way: by producing one or more new GitHub issues.

That is useful because it means the exploration is not just “context”. It turns into concrete follow-up work with clear boundaries. Once that happens, I can close the research loop and go back to the per-issue thread pattern.

Why this works better than over-orchestration

This workflow is intentionally not an agent-swarm post.

I am not trying to simulate a company org chart inside the app. I do not want elaborate coordination machinery unless the problem genuinely demands it. Most day-to-day engineering work benefits more from clear boundaries than from more moving parts.

One inbox thread. One issue tracker. One focused implementation thread per issue. Research threads when they earn their keep.

That is enough structure to keep things tidy without making the workflow feel ceremonial.

Small context, faster app, better history

The biggest benefit is that everything stays small.

Small context means the active thread is easier to reason about. It usually means the app feels faster. It means when I search later, I find a thread whose title actually matches the work that happened inside it. And it means I do not dread opening old conversations because each one has a clear purpose.

That, more than anything, is what I want from a practical coding-agent workflow. Not maximal sophistication. Not a benchmark-optimized orchestration strategy. Just a system that stays readable, searchable, and pleasant after the novelty wears off.

For me, this is the sweet spot: enough structure to keep momentum, not so much structure that the workflow becomes its own hobby.