When I continue coding work in a new session, the files show what exists now but not always why a change was made, what was rejected, or which check still needs to run.
In the interactive workflows I use, Codex and Claude Code write local session logs by default as they work. A session log is a file that records the conversation, tool calls, and results returned by those tools. My workflow reads those files directly when they remain available, which helps recover missing context before the next session continues.
Claude Code’s local transcripts have a separate limit: its cleanup process deletes eligible files on startup once they are older than 30 days by default. Old Claude Code transcripts should not be treated as permanent. My earlier Claude Code session-log retention audit explains where the files are stored and how the setting works [documented as of July 31, 2026, Claude Code application data].
The same records are useful at other scales. A monitor can follow a session that is still running. Search and reporting tools can compare many sessions, find a repeated problem, produce a report, or collect possible topics for later research. The common value is continuity: work that would otherwise disappear with the chat window remains available for my next decision.
The files and the logs answer different questions, though. A log records what an assistant and its tools reported at a particular time. The current project shows what survived after later edits, reviews, and decisions. Because those two records can diverge, every reuse needs a check that matches the claim.
Start with the question
Before asking a tool to read a log, I write down the question I want it to answer. That keeps a search for one missing decision from turning into a vague tour through months of transcripts.
| Goal | What the log contributes | What the workflow checks separately |
|---|---|---|
| Continue interrupted work | Earlier decisions, attempted steps, unresolved questions | Current files, pending changes, and test results |
| Follow a running task | Recent activity and whether the agent is active, waiting, blocked, or finished with a turn | The expected file or result before calling the task complete |
| Study repeated behavior | Comparable records of requests, attempts, corrections, and outcomes reported at the time | The sample, duplicates, classification method, and any cited project evidence |
| Create a plan, report, or article | Candidate findings and useful source trails | Whether each claim is still true, safe to disclose, and worth using |
The loop separates human decisions from tool work. I define the outcome. The tool reads the relevant observations and compares them with current evidence. I choose the next bounded action and decide whether its result is good enough. Activity inside a transcript is not the same as completion outside it.
One session can carry work forward
A request can be as simple as: “Find the logs from yesterday’s work and help me continue it today.” If a relevant log still exists, the log-reading tool can recover the earlier goal, decisions, attempted steps, and unresolved questions. That saves me from rebuilding the conversation from memory, but it does not show that the project files are unchanged or that the earlier approach was correct [personal practice].
Claude Code and Codex also have resume commands that reopen a recorded conversation inside the coding tool [documented for Claude Code; locally verified in the installed Codex CLI help]. The recovery workflow does not invoke those commands. Reading a log and reopening a conversation are separate operations, and neither establishes the current state of the files. The recovery workflow inspects those files before continuing, and I decide whether the evidence is sufficient [documented platform boundary, Claude Code sessions].
For work that must continue, I ask a handoff workflow to make a short note for the next session. The note records the goal, decisions, evidence status, changed files, reversals, and the next check. The pickup workflow compares that snapshot with the current files and Git change history before continuing [implemented workflow, session-end and session-pickup]. Git is the system these projects use to record changes over time.
Logs also let me follow work without opening the whole conversation. A monitor, meaning a program that watches a running task, can reduce recent records to a status such as active, waiting, blocked, stalled, or turn ended. The monitor I use supports both Claude Code and Codex log formats and removes hidden reasoning and raw tool arguments from the status it shows. When a turn ends, the monitor checks the expected file or test result separately before reporting that the objective is complete [implemented and tested, monitor surface notes].
I use the same separation across many projects in Command, a system I built to watch and coordinate work. Its watcher reads session activity beside code changes, automated checks, and service status. A separate interactive session weighs those signals and handles actions that still require approval.
Many sessions can change the next plan
A collection of logs supports a different kind of work. I ask search and analysis tools to reconstruct timelines, compare approaches, find repeated corrections, measure how often a workflow appeared, and locate investigations that stopped before reaching a useful answer. One concrete example is reviewing a multi-agent run: the transcript lets the review check the coordinating assistant’s decisions and whether delegated tasks stayed within their assigned scope.
For this post, I asked separate audit tools to examine my own direct requests across surviving local Codex and Claude Code histories, plus the surviving local desktop history from Cowork, Anthropic’s agent for knowledge work. The audit excluded assistants’ summaries, tool results, system instructions, subagent records, and exact duplicate prompts. The remaining requests included recovering prior decisions, resuming work, monitoring active sessions, creating handoffs and reports, comparing results, analyzing repeated friction, finding writing ideas, and building tools around session history [private log observation; categories only]. That audit establishes that I asked for these uses. It does not show that every request succeeded or that the categories are equally common.
One published retrospective shows the analysis path. Its scanner examined 3,525 transcript files and found 71 times I had asked a separate reviewer to look for flaws. The sessions supplied an inventory of attempts, but the findings still needed checks against the files and recorded code changes. One plausible finding cited a real file and a real proposed change, yet the change was unrelated to the reported vulnerability. A separate search found the actual saved change from the same day’s review, and it fixed different bugs [measured and checked against the cited project history, the published retrospective].
Idea discovery is lighter-weight. I ask a search tool to find recurring friction, abandoned questions, and workarounds that appeared more than once [personal practice]. The output is a candidate queue. The workflow removes private context and checks whether the problem still exists. I decide whether the remaining evidence justifies turning a candidate into a plan.
Where log evidence stops
A session log is strongest when the claim stays close to what it recorded. It can show that I made a request, a tool returned a result, or an assistant reported a conclusion at a particular time. It cannot establish the present state of a changing project by itself.
A weekly report on this site exposed one way the boundary can fail. A project card said there were 6 sessions, then displayed 58 entries built from sessions below it. Both totals came from the logs, but two parts of the reporting code assigned worktree sessions to projects differently. A worktree is a separate working copy created by Git. One counter grouped those sessions under “other” while the other grouped them under the parent project.
The mismatch revealed an attribution bug. The reporting workflow was updated to group worktree sessions consistently. A corrected run regenerated the report, and the report builder gained a check that compares the counters. When readable logs produce inconsistent project totals during a normal live run, report generation now stops instead of publishing the mismatch [locally measured in the site’s committed session-reconciliation test; corrected public report]. The records were available. The reporting layer had combined them incorrectly.
Interpretation can fail too. During an edit to this site, a coding assistant misread my written style guide as banning en dashes, then changed 14 numeric ranges across five posts. The guide banned em dashes. An editorial review workflow compared the report with the actual rule. A later coding assistant reverted the five post edits and narrowed the automated style check that had enforced the mistake [locally verified in the site’s committed voice-profile and linter history]. The log preserved the mistaken reading accurately; the durable rule showed that the reading was wrong.
Time creates a simpler mismatch. A handoff can correctly report a blocker at noon and be obsolete after a coding assistant working in another session resolves it. The repair in all three cases follows the cause: reconcile attribution, check an interpretation against its source, or refresh a stale claim against current state.
Before log material reaches a public page
I do not move raw logs directly into public prose. This site’s weekly report uses three boundaries.
Reduce and redact. A local workflow turns session material into a limited digest and removes details that should not leave the machine. Candidate prose stays in ignored working files that the site cannot publish.
Verify the source. After I accept an item, I move it into a reviewed source file. The report builder checks any saved code change named as primary evidence, and an automated rule rejects unsupported numerals in selected summary fields. Those checks cover specific failure modes; they do not validate every sentence.
Separate publication. A privacy scanner checks the built site for known private terms and identifying patterns. I then review the proposed site change before it can join the published version.
These are properties of this site’s workflow, not guarantees supplied by Codex, Claude Code, or their logs [locally verified in the reviewed work-log source, source validator, report builder, and build tests]. Automated filters can only catch terms and patterns they know about, so human content review remains part of the process.
Retention is part of the design
Claude Code’s current documentation says its local transcripts are plaintext, meaning anyone with access to the files can read them. The 30-day cleanup rule is specific to Claude Code’s local transcript files; it does not establish a retention rule for Codex, separate Claude web or desktop histories, or files deleted manually. Keeping logs longer gives me more history for recovery and analysis. It also keeps potentially sensitive material on disk longer.
I decide which logs are worth retaining and for how long. A handoff or reporting workflow records conclusions that need to survive in proposed project records, and I review those records before accepting them. A test result, saved code change, or decision record is easier to check later than a growing transcript archive.
The division of responsibility is straightforward:
- Logs preserve observations and context.
- Current project evidence determines whether an observation still holds.
- Files and tests show whether a requested change happened within the scope they measure.
- I decide whether the result is desirable and whether it should ship.
To try the workflow, pick one unfinished task rather than an entire archive. Read its most recent session, write down the next decision it informs, and identify the current file or result you will check before acting.