Tracking: Activity Panel, Inline Commenting, Token Display & Client Logger (PRs #64, #67, #72, #75)

[danshapiro]

Summary

This issue tracks a set of related PRs from @bradfeld that add developer experience features around coding CLI sessions. We're consolidating them here to track the effort holistically rather than leaving four PRs open independently.

PRs covered:

• feat: add token usage display + structured client logging #64 — Token usage display in pane headers + structured client logging (createLogger refactor)
• feat: add inline commenting system for terminal output #67 — Inline commenting system for terminal output
• feat: add structured activity panel sidebar #72 — Structured activity panel sidebar (tool feed, token meter, permission approve/deny)
• feat: add inline diff viewer for Edit/Write tool calls #75 — Inline diff viewer for Edit/Write tool calls (builds on feat: add structured activity panel sidebar #72)

What's good

There's a lot of solid work here:

• Activity panel architecture (feat: add structured activity panel sidebar #72/feat: add inline diff viewer for Edit/Write tool calls #75): Clean Redux slice with ring buffer storage, well-typed event normalization, and good component decomposition (ToolActivityFeed, TokenUsageMeter, PermissionActions, ToolDetailPanel, FilePreview). The sdk-message-handler.ts fan-out that routes sdk.assistant, sdk.result, and sdk.permission.request messages into the activity panel store is well-structured.

• Inline diff viewer (feat: add inline diff viewer for Edit/Write tool calls #75): Pure diff-utils.ts with line-level + word-level highlighting. The DiffView component supports compact mode and maxLines truncation. Good separation of concerns.

• Inline commenting (feat: add inline commenting system for terminal output #67): Complete feature with comment queue, flush-on-turn-complete semantics, keyboard shortcut (Ctrl+Alt+M), popover UI, gutter display, and a guard modal for unsent comments on pane close. This PR had zero findings across two fresheyes reviews.

• createLogger refactor (feat: add token usage display + structured client logging #64): The component-prefixed logger factory (createLogger('App') → log.warn(...)) is a nice quality-of-life improvement over raw console calls. Level-filtered, clean API.

• Test coverage: The PRs collectively add 100+ new passing tests across unit and integration suites.

What doesn't seem to work

When we combined all four PRs and tested them, the activity panel sidebar renders and toggles correctly, but shows no data for terminal-mode coding CLI sessions (the primary way people use Claude Code in Freshell).

The root cause: the activity panel's data pipeline is wired to two message paths:

1. sdk.* messages (Freshclaude headless sessions via ClaudeChatView → sdk.create) — This path works. sdk.assistant fans out tool calls, sdk.result fans out token usage, sdk.permission.request fans out approvals.

2. codingcli.event messages (the older codingcli.create path) — This path is wired in the handler but codingcli.create is only dispatched from codingCliThunks.ts, which is never imported anywhere. Dead code.

Neither path covers terminal-mode sessions where Claude Code runs as a PTY process (mode: claude). The activity panel toggle appears for these panes (because mode !== 'shell'), but no events ever arrive.

Additionally:

• The remote log collector (createClientLogger().installConsoleCapture() in main.tsx) monkey-patches every console.* method and POSTs batches to /api/logs/client — but that server endpoint doesn't exist. It silently retries against a 404 every 2 seconds.
• The approve/deny buttons send codingcli.approval WS messages. The server handler exists but only applies to codingcli.* sessions, not sdk.* sessions (which use sdk.permission.respond).
• PR feat: add token usage display + structured client logging #64's UsageBar in pane headers reads from paneRuntimeMeta?.tokenUsage, which doesn't appear to be populated by the terminal metadata service for any session type.

Questions

1. Was this designed for Freshclaude specifically? The sdk.* data path works, so if the intent was to support the chat-based UI rather than terminal-mode sessions, the architecture makes sense — it just needs the toggle hidden for terminal panes that can't populate it.

2. Is there a plan to bridge terminal-mode sessions? Extending the activity panel to PTY-based Claude Code sessions would require a fundamentally different data source (e.g., parsing the terminal output stream, or reading from the JSONL session files in real time). Was this on the roadmap?

3. What's the intended use for the remote log collector? Should we add the server endpoint, or was this scaffolding for a future observability feature? The console monkey-patching in production is a meaningful change to debug workflows.

4. Inline commenting (feat: add inline commenting system for terminal output #67) — this is the most self-contained of the four. It works independently of the activity panel data pipeline. Should we consider landing it separately?

---

This issue was created by Claude Code after reviewing and test-merging all four PRs together. Build passes, +103 tests vs main, no new test failures. The code quality is generally high — the gap is in the data pipeline connecting the UI to the session types people actually use.