What Is a Claude Code Session Trace (and Why It Belongs in Your PR) · vibeshub

When you pair with Claude Code, a lot happens between “here’s what I want” and “here’s the diff.” The agent reads files, runs commands, hits dead ends, backs out, and tries again. By the time a pull request lands, all of that reasoning is gone. Your reviewer sees the destination but not the route.

A session trace is the route. This post explains what a Claude Code session trace actually captures, why it matters more for AI-assisted code than for code you wrote by hand, and how attaching one to a PR changes the review conversation.

What a session trace captures

A Claude Code session is a back-and-forth: you describe an outcome, the agent investigates and acts. Along the way it generates a stream of activity that ordinarily lives only in your terminal and then disappears when you close it.

A trace preserves that stream as a readable record:

The prompts — what you asked for, in order, including the follow-ups and corrections.
The tool calls — which files Claude read, what commands it ran, what it searched for.
The edits — the changes it proposed and applied, in sequence rather than collapsed into one final diff.
The decision points — where the agent chose one approach, hit a problem, and changed direction.

The diff in your PR is the result of all that. The trace is the reasoning behind it. Those are two different artifacts, and reviewers need both.

Why AI-assisted code makes the trace matter more

For human-written code, the diff plus a decent PR description usually tells the story. The author made deliberate choices and can explain them. Reviewers have decades of shared intuition about how people write code.

AI-assisted code breaks some of those assumptions:

Intent is harder to infer. When a function looks slightly unusual, a reviewer can’t tell whether the author chose that deliberately or whether the agent settled on it after three other attempts failed. The diff alone doesn’t say.

Confident-looking code can be wrong. Agents produce clean, plausible code even when they’ve misread the codebase or invented an API. Reviewers end up re-deriving the reasoning from scratch just to trust the output — slow, and easy to get wrong.

Scope can drift. A session that started as “fix this bug” sometimes wanders into refactors the reviewer never expected. Seeing the prompts makes the scope obvious instead of a surprise.

In every one of these cases, the missing information is the session — and that’s exactly what a trace restores.

What this does to code review

Reviewing an AI-generated PR without the session is detective work. You read the diff, guess the intent, mentally reconstruct what the author was probably trying to do, and check the code against that guess. It’s slow, and it puts the burden of reconstruction on the person with the least context.

Attach the trace and the review changes shape:

Intent is given, not guessed. The prompts state the goal directly.
You can audit the path, not just the endpoint. If a change looks odd, you can see the step that produced it.
Scope is visible. What the session set out to do, and what it ended up touching, are both on the page.
Approval gets faster. Less time reconstructing context means more time on the parts of review that actually need judgment.

The trace doesn’t replace review — it removes the guesswork that makes AI-PR review tedious.

The obvious objection: “I’m not pasting my session anywhere”

This is the right instinct. A raw session can contain API keys, tokens, environment variables, internal paths, and other things that should never leave your machine — let alone land in a pull request.

vibeshub is built around that concern:

Redaction happens locally first. Secrets are stripped before anything is uploaded, so sensitive values never leave your machine in the clear.
A second redaction pass runs server-side. It’s a backstop, not the only line of defense — two stages, not one.
Access mirrors GitHub. Visibility follows your repo permissions. People who can see the repo can see the trace; people who can’t, can’t. There are no separate access lists to configure or forget to lock down.

The point of a trace is to add context to review — not to add a new way to leak credentials.

Where traces fit in your workflow

The natural home for a trace is the pull request. You finish a Claude Code session, post the trace to the PR, and reviewers get the diff and the reasoning in the same place. No screenshots, no pasting logs into a chat thread that’s unsearchable an hour later.

Traces also stand on their own. Not every session is tied to a PR — sometimes you’re debugging, exploring, or showing a teammate how you got somewhere. A standalone trace lets you share that session with the same redaction and the same access rules, without forcing a pull request to exist first.

The takeaway

The diff tells you what changed. As more of your code starts in an AI session, “what” stops being enough — reviewers need why, and that lives in the session, not the diff. A trace captures the session, redacts what shouldn’t be shared, and attaches it where the review actually happens.

If your team is reviewing AI-generated PRs by reverse-engineering intent from the diff, the trace is the missing half of the artifact.