When I continue coding work in a new session, the files show what exists now. They do not always show why a change was made, which approaches I rejected, or which check still needs to run.
That context is what I need to decide where the next session should start. It identifies the problem the work was trying to solve and where the previous session stopped.
Codex and Claude Code save local session logs by default during interactive coding sessions, and my earlier audit explains where Claude Code stores its files. A session log is a file that records the conversation, tool calls, and results returned by those tools. When a readable log still exists, a log-reading program can inspect it directly and recover details that never made it into the project files.
One log helps me continue one piece of work. A collection of logs helps me see how work developed across sessions: the decisions that kept recurring, investigations that went unfinished, and ideas that are worth turning into a plan or report.
Recover the decision behind the files
Before asking a tool to read a log, I write down the question I need answered. It might be why a change was made, what had already been tried, or which result the previous session was waiting for. A narrow question keeps the search tied to the next decision.
For interrupted work, the log-reading program can recover the earlier goal, the options that were considered, the approach that was chosen, and any unresolved checks. I can then compare that context with the current project and decide where to continue [personal practice].
For work that needs to pass between sessions, I ask a handoff workflow to turn the useful context into a short note. A handoff is a record for the next session, not a copy of the whole conversation. Mine includes the goal, decisions, changed files, rejected approaches, evidence status, and next check. The public session-end and session-pickup workflows implement this by checking the note against the current files and Git’s record of later file changes before work continues.
That same recovery material is useful after a mistake or an interrupted experiment. I can find the last known reasoning, see which paths had already failed, and avoid repeating work just because its conclusion never reached a permanent document.
Follow work without reopening the conversation
Logs can also show what a session is doing while it runs. A monitor, meaning a program that watches a task, can reduce recent activity to a small status such as active, waiting, blocked, or finished with a turn. I use that status to decide whether a task needs attention without rereading its full conversation.
The monitor’s published notes document support for both Claude Code and Codex log formats. Its status leaves out the assistant’s internal reasoning and the full arguments sent to tools, with both formats covered by public implementation tests. When the watcher reports that a turn ended, the surrounding monitoring workflow checks the expected file or test result before calling the task objective complete. Those behaviors belong to this local monitor, not to the coding platforms themselves.
I use the same pattern across projects in Command, a system I built to watch and coordinate work. Session activity sits beside code changes, automated checks, and service status. The logs supply recent context; the other signals show whether anything durable changed.
Repeated work becomes planning material
I use the same kind of search to find recurring friction, abandoned questions, and workarounds that appeared more than once [personal practice]. A repeated problem can become a test to add, a workflow to repair, or a research question to schedule. An unfinished idea can become a candidate for a later article. The logs provide the trail; I decide whether the candidate deserves more work.
Once a finding is worth keeping, I move it into a smaller record that fits its next use. Active work gets a handoff. Several sessions can become a report. Repeated friction can become a plan. I start the next session from that record without making the tool reread an entire archive.
The boundary I keep
A log records what a person, assistant, or tool observed at a particular time. The current project determines whether the observation still holds. This site’s weekly report once showed 6 sessions on a project card and 58 entries below it because two parts of the reporting code grouped the same records differently. The repair aligned the grouping and added a reconciliation test [locally measured, corrected public report].
Availability and privacy limit reuse too. Claude Code stores local session data as plaintext and, by default, deletes eligible transcript files on startup after 30 days [documented as of August 1, 2026, Claude Code application data]. That claim does not cover Codex. Raw logs can contain prompts, paths, identifiers, secrets, and private project details, so I keep them out of public writing. For this site’s reports, a local workflow reduces and redacts candidate material, checks selected claims, and scans the generated weekly-report, archive, and goals pages for known private terms and patterns. I review the proposed change before publication. None of those safeguards come from the coding platforms.
If you use a coding assistant that leaves readable logs on your machine, try this on one unfinished task. Find the most recent retained log relevant to that work, then write a short handoff with the goal, the last decision, one rejected approach, the unfinished check, and the next action. Compare that note with the current project before continuing.