[FEATURE] Debug command to view the full chronological content of the context window

A first-class /context --full would be great, and I'd use it too. Until it exists, there's a ground-truth source you can dump today that covers most of what you're describing: the session transcript JSONL.

Every turn is appended in assembly order to ~/.claude/projects/<encoded-project-path>/<session-id>.jsonl, one JSON object per line. The line order is the chronological order, and each object is typed. From poking at my own current session:

• type: "user" / type: "assistant" carry .message.role and .message.content[], where each content block has its own .type: text, thinking, tool_use, tool_result.
• Injected context shows up here too: <system-reminder> blocks and hook additionalContext land as text blocks inside user messages (that's where things like hook output and reminders appear), so you can see where in the timeline they landed.
• Tool calls and their results are separate, ordered entries (tool_use in an assistant turn, the matching tool_result in the next user turn).

A quick annotated chronological dump:

f=$(ls -t ~/.claude/projects/*/$(... your session id ...)*.jsonl | head -1)   # or pick the file directly
jq -rc 'select(.type=="user" or .type=="assistant")
  | .message.role as $r
  | (.message.content
      | if type=="string" then [{type:"text",text:.}] else . end)[]
  | "\($r)/\(.type)\t" +
    ( .text // .thinking // (.name // "") // "" )[0:200]' "$f"

That gives you role/blocktype + a snippet, in load order — enough to verify "did the hook inject the wrong thing / did a reminder appear in an unexpected place / did context load out of order," which is exactly the harness-debugging case.

Honest caveats so this doesn't mislead:

• The JSONL is the per-message assembly record. The static front matter of a request — the system prompt and the tool definitions block — is added by the client at request time and is not stored per-line in the transcript, so a /context --full that also rendered those verbatim would still be strictly better than this workaround.
• tool_result content can be large/truncated-on-display; the JSONL has the stored form, which may differ from what was actually sent if the client elides.

So this isn't a full substitute for the feature you're asking for — the system-prompt + tools portion and a guaranteed "exactly what was sent" guarantee are the parts only a built-in command can give you. But for "what landed in the timeline and in what order," the transcript is a usable ground truth today.

Fully agree with this request. Context ordering is the part of harness development that is currently pure guesswork, and the existing /context budget view does not help because the problem is never "how many tokens am I using in category X" - it is "in what order did the model see things, and did my hook injection land before or after the task description."

A few additions that would make this even more useful:

1. Show the effective prompt order across all sources: system prompt, CLAUDE.md, skills, hook output, user messages, tool results. Right now these all arrive at slightly different points and there is no ground-truth trace.

1. For tool results specifically, show which tool call triggered each result and whether it was truncated. Silent truncation of MCP server output is a major source of harness bugs where the agent acts on partial information.

1. Export as JSON should include the raw token boundaries if possible (or at least byte offsets) so you can correlate the context dump against the model's attention patterns in offline analysis.

The use case for harness builders is concrete: when a subagent returns unexpected output, the first debugging question is always "what did it actually see?" Right now the answer is "probably whatever we think we sent, plus whatever the runtime injected, in some order." That is not a sustainable debugging environment for anyone building reliable systems on Claude Code.

Update: while waiting for a first-class /context --full, I built a tool that renders the view I was asking for here, reconstructed from the session transcripts — if you have a similar need, feel free to check it out:

https://github.com/gigayaya/context-render

It's a local, read-only CLI (no API calls, no telemetry). For each session it shows:

• File loads — everything that entered the context, in injection order, with the load mechanism and which scaffold component it's attributed to
• Timeline — the session as a chronological event list (hooks firing, CLAUDE.md injection, reads, bash, writes), with loaded/invoked markers
• Context-window map — when tokens entered the window and what put them there, with cumulative occupancy
• Cross-session aggregates (report / deadweight) to find scaffolding that never gets used

Essentially it's @yurukusa's transcript-based approach, engineered into a full tool — so it shares the same honest ceiling: the transcript doesn't contain the static system prompt / tool definitions, and it's a post-hoc reconstruction rather than a guaranteed byte-exact record of what was sent. A built-in command would still be strictly better, and I'd still love to see this feature land. But for the harness-debugging loop ("did my hook injection land where I expected, and in what order?"), it's been a usable ground truth for me today.