Where Claude Code Task Output Goes, and How to Keep It

Claude Code’s output is spread across several places, and most of them are temporary. What you see is the terminal. Behind it, every session is saved as a transcript file on your machine and deleted after a retention period. Background commands write to their own output files, subagents keep their own transcripts and hand back only a summary, and a headless claude -p run prints text or JSON to standard output. If a result has to outlive the session, you have to put it somewhere on purpose.

The terminal: what you see

The interactive view is the conversation rendered for reading: your prompts, Claude’s replies, and each tool call with its result. Long tool output is not kept inline. The tools reference↗ (opens in a new tab) says a command’s result is shown inline up to roughly 30,000 characters by default; past that, Claude gets the path of a file saved to the session directory and a preview of the first 2,000 characters, and reads the file when it needs the rest.

To keep a readable copy of a whole session, run /export. It copies the conversation to the clipboard or saves it as a plain-text file, with tool output rendered as text; pass a filename to write straight to it.

Session transcripts on disk

Every session is saved continuously as you work. The sessions documentation↗ (opens in a new tab) gives the location: JSON Lines at ~/.claude/projects/<project>/<session-id>.jsonl, where the project folder is your working directory with non-alphanumeric characters replaced by dashes. Transcripts are kept for 30 days by default, and cleanupPeriodDays in settings.json changes that.

• claude --continue reopens the most recent conversation in the current directory.
• claude --resume opens a picker; claude --resume <name> or a session ID goes straight to one.
• Sessions started with claude -p are left out of the picker and out of --continue, but can still be resumed by ID.
• The line format is internal and changes between versions, so the documentation advises against parsing these files in scripts; use /export or the headless interfaces instead.
• The opposite need exists too: --no-session-persistence on a claude -p run stops that one run writing a transcript at all, which suits a scheduled job whose only output that matters is what it prints.

A resumed session restores the conversation, including tool calls and results. It does not restore background shells or monitors, which is the next place output goes missing.

Background tasks

A long command — a test suite, a dev server, a build — can run in the background while the conversation carries on. According to the interactive mode documentation↗ (opens in a new tab), its output is written to a file that Claude reads with the Read tool, each task has an ID, and background tasks are cleaned up when Claude Code exits. You can list and stop them with /tasks. The practical consequence: if a background test run matters, have Claude summarise the result into the conversation or a file before the session ends. The post on Claude Code background tasks covers starting and stopping them.

Subagents: only the summary comes back

A subagent works in its own context and returns only a summary to the main conversation. Everything it read and ran stays in its own transcript. The subagents documentation↗ (opens in a new tab) puts those transcripts at ~/.claude/projects/{project}/{sessionId}/subagents/agent-{agentId}.jsonl, says they are unaffected when the main conversation compacts, and deletes them on the same 30-day retention period.

That design is why subagents are useful — the main thread stays clean — and why their detail is easy to lose. If the reviewer subagent found six problems and the summary mentions three, the other three are in a file nobody will open. Ask subagents for a fixed shape of answer: a list of findings with file and line, or “none”. The subagent examples post has files that do this.

Headless runs: choose the format

claude -p runs one prompt without the interactive interface and prints the result. The headless documentation↗ (opens in a new tab) lists three output formats: text (the default), json, which wraps the result with the session ID and metadata, and stream-json, newline-delimited events for real-time use. Add --json-schema to get a structured_output field that matches a schema you supply.

# Plain text, straight into a file
claude -p "Summarise what changed in the last five commits" > summary.md

# JSON: keep the answer and the session ID to resume later
claude -p "Review src/payments for missing error handling" --output-format json > review.json
jq -r '.result' review.json
jq -r '.session_id' review.json

The session ID is what lets a script come back later with claude -p --resume <id> and ask a follow-up, such as “list what you changed”. For turn limits, permissions and running this unattended, see how to automate Claude Code tasks.

What disappears, and when

• Terminal scrollback: when you close the terminal.
• Background task output: when Claude Code exits, and it is not restored on resume.
• Session and subagent transcripts: after the retention period, 30 days unless you change it.
• Detail inside a subagent: never deleted early, but never read either unless someone opens the file.
• Headless output: whatever you did not redirect or capture.

How to keep what matters

None of those places is meant to be a record. Decide what the durable output of a task is, and have Claude put it there as part of the task.

1. Ask for a file. “Write the findings to docs/reviews/payments.md” turns a reply into something in the repository, with version history.
2. Capture headless output. Redirect it, or keep the JSON, in the job that ran it.
3. Use a hook for the last word. The hooks reference↗ (opens in a new tab) says hook input includes transcript_path, and the Stop and SubagentStop events carry last_assistant_message, the final text of the turn, so a hook can append it to a log without parsing the transcript. SessionEnd hooks run on a short time budget, so keep any archiving there quick.
4. Put the result on the task. The outcome — what changed, the commit, how it was tested — belongs where the rest of the team looks, not in a transcript on one laptop.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.last_assistant_message' >> .claude/turn-log.md"
          }
        ]
      }
    ]
  }
}

Putting the result on a board

With fenbs connected over MCP, the last step is two calls. fenbs_comment adds what happened to the task — the commit, the files, anything left undone — and fenbs_update_item sets its Testing status and notes and moves it to Completed. Both are recorded in the board’s history as “Claude via” the person who connected it. The transcript can expire on schedule; the task keeps the part anyone will ask about.

A result comment worth keeping answers four questions in a few lines: what changed, where it is (the commit or pull request), how it was checked, and what was left undone or noticed along the way. The last one matters most with agents, which often see problems they were not asked to fix. Filing those as new tasks, rather than leaving them in a transcript, is how they get fixed at all.