Feedback submission (/bug) crashes long-running sessions — payload appears to scale with session size, killing background subagents

Summary

In a long-running session, submitting feedback via the in-app feedback flow (/bug) reproducibly crashes the entire Claude Code process. It happened three times today in the same session, each attempt within seconds of submitting. The apparent mechanism is memory: the box shows a large allocation spike on submit, and the process dies without an error message. Each crash also tears down all running background subagents, which is the expensive part of the failure — hours of in-flight agent work (an Opus review run, a Playwright witness run) died with the host process each time.

Environment

• Claude Code CLI 2.1.231, Linux (openSUSE, kernel 6.19.12), zsh
• Host: 9.6 GiB RAM VM; swap 4 GiB (fully consumed after the crashes)
• Session characteristics at time of crash:
• main transcript: ~76 MB, ~27,500 JSONL records
• subagent transcripts under the session directory: 751 MB total
• several background subagents live (spawned via the Agent tool)

Steps to reproduce

1. Run one session for many hours with heavy subagent use until the session directory is large (tens of MB main transcript, hundreds of MB of subagent JSONL).
2. Invoke the feedback flow and submit a report.
3. The CLI process exits abruptly; no crash message reaches the terminal. On restart, the SessionStart hook fires and background agents are gone.

Three for three today in this session; smaller/younger sessions submit feedback fine on the same machine.

Expected

Feedback submission should be O(feedback text), or at minimum stream/truncate any diagnostic payload it attaches. It should not scale with session lifetime, and a failure to assemble the payload should error inside the session rather than killing the process (which also kills background agents that have no recovery path — resuming them after restart fails with "No transcript found for agent ID" in some cases).

Guess at mechanism

Behavior is consistent with the feedback path reading the full session transcript (possibly plus subagent transcripts) into memory to build the diagnostic attachment. On a 9.6 GiB host that is already running the session's own node processes, a multi-hundred-MB JSON parse/stringify plausibly OOMs the process. If so, streaming the payload, capping it to a tail window, or excluding subagent transcripts would fix it.

Happy to supply timestamps, the session's file-size listing, or anything else useful.