Problem
There is no in-app way to see what the client is doing. Diagnosing a misbehaving session today requires the user to open DevTools, know what to record, and relay findings by hand.
This was the bottleneck in a recent investigation into a tab burning ~18% of a core for three days. Identifying the cause required inspecting Chrome process and per-thread CPU from outside the browser, because the client itself could report nothing about its own behavior. The runaway then stopped mid-investigation and the evidence was lost — with a diagnostics buffer it would have been captured.
Proposal
An opt-in diagnostics capture with a one-click export.
In Preferences:
- A checkbox: Capture diagnostics (off by default).
- A button: Copy diagnostics — serializes the buffer to the clipboard as Markdown, ready to paste into a GitHub issue.
Behind it: a bounded ring buffer (size-capped, so it cannot grow without limit the way an uncapped log would) holding structured records.
What the export should contain
Environment
- User agent, platform,
hardwareConcurrency, deviceMemory
- Window size,
devicePixelRatio, page uptime
- App version / build hash
Session state
- Connection status, transport, reconnect count
- Which optional subsystems are live: audio, MIDI, voice chat, haptics/gamepad, editors, file transfers
AudioContext.state
Counters and rates (sampled, not per-event)
- Messages/sec inbound, output lines/sec
- Animation frames/sec
- React render counts for the hot components
- Long-task count and total duration
Recent events
- Console warnings and errors
- Performance watchdog records (see linked issue)
- Connection lifecycle events
Privacy
The export will contain the character name, room names, and potentially message text. That must be explicit, not surprising:
- State clearly in the UI what the export includes, before the user copies it.
- Never include passwords, tokens, or credentials.
- Consider a "redact message text" toggle for users who want to share timing data without conversation content.
- Keep the checkbox off by default and the buffer in memory only — do not persist to
localStorage or IndexedDB unless the user explicitly opts in.
Notes
Designed to pair with the performance watchdog issue: the watchdog produces the records, this feature is how they reach a developer. Useful well beyond performance work — connection drops, audio failures, and file-transfer bugs would all benefit from a one-paste report.
Problem
There is no in-app way to see what the client is doing. Diagnosing a misbehaving session today requires the user to open DevTools, know what to record, and relay findings by hand.
This was the bottleneck in a recent investigation into a tab burning ~18% of a core for three days. Identifying the cause required inspecting Chrome process and per-thread CPU from outside the browser, because the client itself could report nothing about its own behavior. The runaway then stopped mid-investigation and the evidence was lost — with a diagnostics buffer it would have been captured.
Proposal
An opt-in diagnostics capture with a one-click export.
In Preferences:
Behind it: a bounded ring buffer (size-capped, so it cannot grow without limit the way an uncapped log would) holding structured records.
What the export should contain
Environment
hardwareConcurrency,deviceMemorydevicePixelRatio, page uptimeSession state
AudioContext.stateCounters and rates (sampled, not per-event)
Recent events
Privacy
The export will contain the character name, room names, and potentially message text. That must be explicit, not surprising:
localStorageor IndexedDB unless the user explicitly opts in.Notes
Designed to pair with the performance watchdog issue: the watchdog produces the records, this feature is how they reach a developer. Useful well beyond performance work — connection drops, audio failures, and file-transfer bugs would all benefit from a one-paste report.