Every Session Event Is Now Visible
When you’re debugging a Claude Code session, the developer timeline in claude-view should show you everything. Until now, three categories of events were silently dropped: context attachment changes, permission mode shifts, and scheduled task triggers.
v0.32.0 closes all three gaps.
What was missing
Claude Code emits structured events for a lot of things: tool calls, hook executions, agent spawns, session boundaries. But three event types were passing through the block pipeline and rendering as nothing:
Attachment events happen when files are added to or removed from Claude’s context mid-session. If you’re using /add to pull in a file, or if the agent’s context window is being managed automatically, you’d see the downstream effects in the tool calls but not the context change itself.
Permission mode changes happen when a session transitions between permission levels — from the default mode that asks before running tools, to the more autonomous modes that don’t. These transitions are meaningful for understanding why the agent behaved differently in different parts of a session.
Scheduled task fires happen when a scheduled Claude agent wakes up and starts work. The agent session would appear in the session list, but the trigger event — the moment something said “start now” — wasn’t visible.
All three were parsed and typed in the pipeline but fell into the default: branch of the renderer with no output.
The fix
Each event type now has a dedicated renderer:
- Attachment blocks show the file names added and removed, with additions in the default text color and removals in red — the same visual shorthand as a git diff.
- Permission mode change blocks show the new mode with an amber badge — a warm color that signals “something about how this session operates changed here.”
- Scheduled task fire blocks show an orange “Scheduled” badge — distinct from permission changes but in the same warm range, since both represent configuration-level events rather than content events.
The compiler now enforces this completeness. The renderer switch statement ends with an exhaustiveness check: if a new SystemVariant is added to the type definition without a matching case, the code won’t compile. The three missing events were caught by exactly this check — they were added to the type and the compiler flagged the missing renderer.
Cleaner hook blocks
A separate fix in this release de-duplicates information in hook progress blocks. Previously, the event name and hook name appeared in both the block header (via the EventCard label) and the block body. They were being rendered twice.
The body now shows only what’s unique to it: the status message and the command being executed. The header carries the full event→name context. For sessions with heavy hook activity — pre-tool validators, live monitors, post-tool loggers — this makes the timeline noticeably less noisy.
Long outputs are also no longer silently truncated. Hard .slice() caps on hook command output and stdout have been removed.
What’s next
- Timeline filtering by block type — filter to show only tool calls, only agent events, or only hook activity
- Cost breakdown by session phase — see where the expensive parts of a session happened
- Improved session replay for scheduled task sessions
Update now
npx claude-view@latestOpen any session with hook activity or context management and check the developer timeline. The events that were invisible before should now be there.