How to Analyze Claude Code and Codex Session Logs Across a Team

Your team runs Claude Code and Codex every day. Any one developer can scroll back through their own session and see what the agent did. Nobody can answer the question you get asked in a planning meeting, which is where the team's agent time goes and which repository is costing the most of it. The data for that answer sits on the machines where those sessions ran, in a format you can parse today, and the local CLI cleanup default is 30 days, with separate rules for Desktop and Cowork. Collecting it is a project with a redaction gate in front of it, not a dashboard you switch on.

What follows is the collection and analysis workflow. If you are still choosing between an OpenTelemetry export, a tracing platform, and reading transcripts, the comparison of those three sources covers that decision first.

Decide how long local transcripts live on your disk

Claude Code writes one JSONL file per session to ~/.claude/projects/<project>/<session>.jsonl. Anthropic's reference for that directory describes the file as the conversation transcript: messages, tool calls, and tool results, along with the system prompt, the tool definitions, and the parameters of each request sent to the model. Subagent runs get their own transcripts under projects/<project>/<session>/subagents/, and tool outputs too large to inline are spilled into projects/<project>/<session>/tool-results/. A collector that reads only the top-level JSONL file will miss both.

Two environment variables move or stop the files. CLAUDE_CONFIG_DIR relocates the whole ~/.claude tree, so a developer who sets it will look to your collector like a developer who ran nothing. CLAUDE_CODE_SKIP_PROMPT_HISTORY stops transcripts and prompt history being written at all, and --no-session-persistence does the same for a single -p run. Check for both before you conclude that someone's sessions are missing.

The retention sweep is the part that sets your deadline. Claude Code deletes transcripts, subagent transcripts, spilled tool results, and file-history snapshots once they are older than cleanupPeriodDays, which defaults to 30. Prompt history in ~/.claude/history.jsonl is kept until someone deletes it, except under the HIPAA configuration, where each sweep also removes entries older than cleanupPeriodDays. claude purge removes a single project's transcripts on request.

One carve-out is worth knowing before you plan around that clock. A session you started or last continued in Claude Desktop or Cowork is kept at any age by default, and giving those an age limit takes a separate desktopSessionCleanupPeriodDays setting. They fall back to cleanupPeriodDays when managed settings supply it or when the HIPAA configuration applies to your sessions. For everything else, the quarter you want to analyze in January is gone unless something collected it in December.

Codex writes its own local session files. Dosu's reader looks for them under ~/.codex, and the layout inside that directory has changed between releases, so confirm it against the version your team has installed rather than hard-coding a path from a blog post. The practical consequence for a collector is the same either way: two runtimes, two file shapes, one aggregate you have to build yourself.

One class of run sits outside this picture entirely. A session that does not execute on the developer's machine leaves nothing in their ~/.claude/projects. Claude Code cloud sessions run on Anthropic-managed infrastructure, and an SSH session runs Claude Code on the remote host from an install under ~/.claude/remote/ there. If your team uses either, a sweep of laptops will under-count without telling you, so decide up front whether those runs are in scope and collect them where they run.

Decide what leaves the laptop before you collect anything

A transcript is the full conversation, not a metrics payload. Anthropic's documentation says the files are plaintext, protected only by OS permissions, and that if a tool reads a .env file or a command prints a credential, that value lands in the session JSONL. Treat every transcript as untrusted input to your export.

Export only the fields your questions need:

• Session and project identifiers, plus timestamps, so you can group by repository.
• Tool names and call outcomes, without the arguments or output, which is where the secrets are.
• Token counters, split into input, output, cache read, and cache creation.
• Repository-relative file paths from an allowlist, never absolute paths.
• Human turns and explicit approvals, so you can find interventions later.
• Task outcome from an external source, such as a CI result or a merged pull request, not the agent's closing message.

Redaction has to run on the machine before anything is sent, and you have to build it. Decant's data lifecycle documentation states that it has no redaction step and that its local archive holds the full transcript content, including tool arguments, tool output, and absolute paths. Test your export against real sessions and fail closed when redaction cannot parse a record.

Normalizing two file shapes into one event stream

Claude Code and Codex record the same session differently, so concatenating their JSONL files gives you a pile rather than a history. Reconstruct each runtime's sessions into a common event shape before any cross-developer rollup.

Decant, Dosu's open source reader (Apache 2.0), covers the local half. It reads Claude Code from ~/.claude/projects, Codex from ~/.codex, Gemini CLI from ~/.gemini/tmp, and OpenCode from ~/.local/share/opencode, normalizes them into a SQLite archive at ~/.decant/decant.db, and makes no outbound network calls at runtime. A developer can look at their own numbers before deciding what to share.

The team half is yours: the redaction step above, a transport that carries only approved fields, an access-controlled store, and a stable project identifier so two developers in the same repository land in the same bucket. Reading one machine is a weekend. Collecting thirty is the actual project.

Learn from the overall pattern, don't rely on just a single, isolated session

A single transcript tells you what happened once. The aggregate separates a bad afternoon from a pattern. Start with four questions.

Which kinds of task consume the budget? Group sessions by task scope rather than line count. In Dosu's replay of 112 Claude Code and Codex sessions on tickets from 60 pull requests in the public cal.diy repository, planning and context gathering took 67% of modeled cost, while the code bucket (edits plus the surrounding build, test, and git commands) took 26%. Costs were modeled at standard API rates and the sessions were not scored for correctness, so treat that as one corpus, not a forecast for your repository.

How much does scope multiply the bill? In the same sample, cross-cutting tasks averaged 4.5 times the modeled cost of self-contained ones for Claude Code and 1.5 times for Codex. Run the same grouping on your own sessions.

Which repositories produce the most retries per session? Rates, not totals, show where the friction is.

Where do people intervene? Separate corrections from routine permission grants, then read each correction alongside the task before deciding it reveals a recurring problem.

Treat the answers as leads. Open two or three of the sessions behind a number before acting on it. What you are looking for is repetition.

Turning a repeated pattern into a committed change

A pattern in the aggregate is a candidate for a change in the repository, and the two common patterns want different fixes.

When agents keep opening the same three files to work out a convention, that convention belongs in AGENTS.md. Verify it against the code first, since what the agent concluded is not automatically right, then write the rule with one real example, commit it, and check later sessions to see whether agents read the file and stopped exploring those paths.

When several sessions fail at the same step, the fix is a troubleshooting note rather than a convention. Dosu found one of these while reading 107 coding sessions on Vercel's AI SDK. Its agents rediscovered 28% of the repository facts they extracted on a different task than the one that first turned them up, 68 facts in all, and the most frequent was a single build requirement that came up in 59 sessions across 40 tickets: workspace dependencies have to be built before a package's tests will run, because the tests import compiled dist/ output that a plain install does not produce. The repository did tell contributors to build first. What it did not do was connect that instruction to the missing-import error an agent hits, which is the part worth writing down.

Be careful about what the count proves. Recurrence tells you an instruction is worth checking and worth writing well. It does not establish that writing it down reduced failures or spend. If you want to know that, compare matched tasks before and after, and expect the measurement to be harder than the fix.

FAQ

Do Claude Code and Codex record tool calls the same way?

No. The two runtimes write different file shapes, which is why a reader has to reconstruct each one's sessions before you can compare tool use across them. Any collector you build or adopt needs a normalization step, and any number you compute across both agents inherits whatever that step decided.

What happens to the logs when a developer switches machines or projects?

They stay on the machine that wrote them. Claude Code groups transcripts by project path, so moving or renaming a checkout changes where new sessions land, and CLAUDE_CONFIG_DIR moves the whole tree somewhere else. None of it follows the developer to a new laptop, and the original machine's configured cleanup policy still applies, including the separate Desktop/Cowork retention rules.

Does any of this change how developers work day to day?

Not if you collect after the fact. The transcripts are written unless someone has turned persistence off, and a local reader needs no change to how an agent is invoked. What does change is that someone has to decide what gets exported, who can read it, and when it is deleted. Settle that before the first collection runs, not after.

Can we skip aggregation and just read our own sessions?

For a first look, yes, and it is the right place to start. One developer's archive will show you whether context and planning dominate your sessions and which files get reopened. What it cannot show you is whether a pattern is yours or the team's, and that distinction is what decides whether a fix belongs in your own notes or in the repository.

Start with one machine, then decide what is worth collecting

Before you scope a collection pipeline, find out whether there is anything in your logs worth collecting. On a machine with sessions in ~/.claude/projects or ~/.codex, install the reader and run the three read commands:

npm install --global @dosu/decant@latest
decant stats --by model
decant economics
decant files --group path --op read

If you would rather click than read terminal output, npx @dosu/decant@latest opens the same archive in a local web UI and keeps running until you stop it.

If economics shows most of your spend going to context and planning, files ranks the paths your agents read most. A path at the top of that list is a lead, not a finding: the count alone does not tell you whether unrelated tasks kept re-deriving the same thing. Open a few of the sessions behind it and read what the agent was doing before you take it to the team.

Then close the loop on one of them. Pick a convention your agents keep re-deriving and verify it against the code. Create a Library and connect that repository, configure your coding agent with npx @dosu/cli setup, and ask it to record the verified convention with write_knowledge. In a later session on the same repository and branch, ask the agent to retrieve it with read_knowledge before exploring again.