How can developers keep track of multiple Codex and Claude Code sessions?

Record where each task stands

Use an issue tracker, a Markdown file outside the repository, or a simple note database. The storage choice matters less than keeping one row or card for each active session. Do not make a new card for every question inside a long task. Make one when the work has a distinct output, owner, or checkout.

Use the same status vocabulary everywhere. Blocked should name the blocker, such as “waiting for production sample” or “cannot reproduce locally,” not merely mean that the agent stopped. Ready for review means the proposed change and evidence exist but a person has not accepted them. Done means the task's stated outcome has been reached and its artifacts are linked.

Name tasks for the outcome

Start every agent session with the task name and a one-sentence boundary. For example: “Task: storefront / checkout / fix tax rounding. Change the rounding boundary only. Do not alter checkout UX. Done when the EUR integration fixture passes and the PR explains the behavior.” This name can become the first line of the task record and the chat title.

In the Codex desktop app, rename chats with a short outcome-oriented title, pin the work you return to often, search by a phrase or branch name, and archive finished chats. The current product documentation notes that pinning changes sidebar placement only, while each chat remains its own transcript. Codex projects and chats In Claude Code, record the session ID when it matters. Its current CLI supports continuing the recent conversation in the current directory and resuming a named or identified session. Claude Code CLI reference

Keep durable context in files that future sessions can read

Conversation history is useful for the current task, but it is a poor home for facts that many future tasks need. Put build commands, test commands, important constraints, architecture decisions, and directory-specific rules in versioned project guidance. Put a task's temporary state in its task record or issue.

Codex reads AGENTS.md before it starts work and combines global and project instructions according to directory scope. Codex AGENTS.md documentation Claude Code starts a fresh context window for each session. Its CLAUDE.md files and optional auto memory carry project instructions and learned notes into future sessions, but Anthropic documents them as context rather than hard enforcement. Claude Code memory

If the repository must support both tools, keep shared, durable guidance in one checked-in source. For example, a project can maintain AGENTS.md and have CLAUDE.md import it, then add only Claude-specific rules where necessary. Anthropic documents that pattern explicitly. Sharing AGENTS.md with Claude Code Do not put personal credentials, customer data, or an ever-growing daily work log in either file.

Link to the output and test results

At the end of a meaningful session, update the task record before starting something else. Add the branch or worktree path, the latest commit or diff state, the files changed, commands run and their result, unresolved questions, and the next decision. A branch and test log are better evidence than “agent says finished.”

This also makes a handoff across tools possible. Claude Code may have explored a failure and Codex may implement the repair, but the second session should receive the linked issue, reproducible command, failing output, relevant files, and guardrails. It should not be asked to infer those facts from a broad instruction such as “continue the auth work.”

Use separate working directories for concurrent edits

Separate working directories help when two active sessions could modify the same repository, need different branches, or require incompatible local setup. They are unnecessary for read-only investigation, a short review, or sequential substeps of one change. Adding a worktree creates another copy of repository files and reduces edit collisions, but it also adds a branch, environment, and cleanup obligation.

Codex worktrees are Git checkouts that allow different branches to be worked on in parallel. The current documentation says a chat can be handed between a local checkout and its associated worktree, and that the chat returns to the same worktree when handed back. Codex worktrees Claude Code likewise documents claude --worktree feature-auth for parallel work on separate branches. Claude Code common workflows

Assign a worktree to one change at a time. Record its path and branch in the task card, run the project's setup checks there, and make the worktree owner responsible for creating a commit or a reviewable diff before closing it. A worktree isolates files and branch checkout. It does not merge chat history, decisions, or uncommitted intentions between agents. If a task needs another session's findings, put those findings in the task record, issue, design note, or commit message first.

Example

Hypothetical situation: Maya has three tasks in the storefront repository. A Codex session is implementing a checkout calculation change in codex/tax-rounding. A Claude Code session is investigating a flaky integration test in claude/payment-fixture. A third session is reviewing documentation and makes no edits.

Maya gives each task a separate card. The first two cards record their worktree path, branch, status, and next command. The documentation task uses the normal checkout because it is read-only. When the Claude session discovers that the fixture uses the wrong currency, Maya records the failing command and source file on its card. Codex can then act on that evidence in its own worktree without needing access to the Claude transcript or risking a collision with the fixture investigation.

Resume with a short handoff instead of a broad prompt

Use this five-line handoff whenever you resume a task, switch tools, or ask a new agent to help:

1. Goal: the observable outcome and scope boundary.
2. State: branch or worktree, changed files, and the strongest current evidence.
3. Constraint: what must not change, relevant permissions, or a decision already made.
4. Next action: one bounded investigation or edit to start with.
5. Done when: the validation evidence that closes the task.

For the tax example, the handoff might state: “Goal: correct EUR tax rounding in the API only. State: branch codex/tax-rounding, unit tests pass, checkout_eur integration fixture fails at line 42. Constraint: preserve existing USD behavior. Next action: reproduce the fixture and locate the rounding boundary. Done when both currency fixtures pass and the diff is reviewed.” That is enough context to make the next session useful without copying a long transcript.

Use the product controls to locate the session after reading the handoff. Codex CLI documents codex resume as a stable command that continues a previous interactive session by ID or the most recent chat. It limits --last to the current working directory unless --all is passed. Codex developer commands Claude Code documents claude --continue for the recent conversation and claude -r or --resume for a selected session. Its claude agents --json --all output can list active and completed background sessions, and --cwd narrows that view to a directory. Claude Code CLI reference

Avoid running a resume command before checking the task card's recorded checkout. Codex notes that a saved chat retains its recorded working directory while reading files from the current working tree. Codex projects and chats A resumed conversation can therefore be coherent while pointed at the wrong branch if the operator has moved or reused the directory.