Hey guys,
If you've been deep in a Cowork project and every message suddenly comes back with "Request too large (max 32MB). Try with a smaller file.", your conversation is bricked.
Deleting attachments didn't help me, since the cap is on the whole request payload, not any one file. Asking Claude to "compress the file" (I'm a noob, Claude told me this only works in Code) doesn't help either, because Claude can't respond at all.
The fix is to start Claude Code and give it a recovery prompt. Cowork stores the transcript locally as JSONL, and Code is comfortable doing disk-spelunking with find/grep/jq, so it can read the transcript carefully (the file is huge) and produce a handover doc. Then you go back to Cowork, start a new chat with the same project folder, and paste the handover in to seed it.
Here's the exact thing I pasted. Tweak the project name and the time window for your case:
Code gave me a ~20KB markdown handover covering project overview, files touched, the decisions we'd locked across the conversation, what was happening in the last 30 minutes before the brick, open threads, and the context to carry over. Then I opened a fresh Cowork chat in the same project folder, pasted the handover in, and was back to work in five minutes.I'm working in Claude Cowork on macOS and my conversation just got bricked (within the last 2 hours) with a "Request too large (max 32MB)" error. I cannot send any more messages in that conversation, and there's no way to recover from inside the app. I need you to extract the transcript so I can hand off context to a fresh Cowork session.
The project is called "<YOUR PROJECT NAME>".
## Step 1: Locate the bricked conversation
Search these paths for files modified in the last 2 hours:
- ~/.claude
- ~/.claude-mem
- ~/Projects
- ~/.claude.json
- ~/Library/Application Support/Claude
Run:
```bash
for path in \
"$HOME/.claude" \
"$HOME/.claude-mem" \
"$HOME/Projects" \
"$HOME/.claude.json" \
"$HOME/Library/Application Support/Claude"; do
if [ -e "$path" ]; then
echo "=== $path ==="
find "$path" -type f -mmin -120 \( -name "*.json" -o -name "*.jsonl" -o -name "*.md" -o -name "*.log" \) 2>/dev/null \
-exec ls -lah {} \; | sort -k5 -h -r | head -30
fi
done
```
Also do a broader search ignoring extension, in case the transcript has no extension:
```bash
find "$HOME/.claude" "$HOME/.claude-mem" "$HOME/Library/Application Support/Claude" -type f -mmin -120 2>/dev/null \
-exec ls -lah {} \; | sort -k5 -h -r | head -30
```
And specifically look for anything matching the project name:
```bash
grep -rli "<YOUR PROJECT NAME>" "$HOME/.claude" "$HOME/.claude-mem" "$HOME/Library/Application Support/Claude" 2>/dev/null
grep -rli "<YOUR PROJECT NAME>" "$HOME/Projects" 2>/dev/null | head -20
```
## Step 2: Identify the right transcript
Heuristics:
- It's the largest recently-modified JSON/JSONL file (it bloated past 32MB — that's the whole reason it's broken). For Cowork, look under ~/Library/Application Support/Claude/local-agent-mode-sessions/<...>/local_<sessionid>/.claude/projects/<...>/ — segments cap around 150MB each before rotating, so you may see several
- UUID-style filenames are likely candidates
- Confirm by inspecting the first ~100 lines: it should contain keys like "role", "user", "assistant", "content", "tool_use", "tool_result"
If multiple plausible candidates exist, list the top 3 with: full path, size, modified time, and a preview of the first user message. Then ask me which one before extracting. Don't guess.
If the file looks like a LevelDB store, SQLite db, or other binary format, stop and tell me — extraction needs a different approach.
## Step 3: Extract project state into HANDOVER.md
Read the identified transcript and produce ~/Desktop/HANDOVER.md with:
1. Project overview — what the project is about, inferred from the first few user messages and any project instructions
2. Files touched — every file path that appears in tool calls. Group by: created, modified, read-only-referenced. Include full paths.
3. Decisions made — key choices, approaches agreed, things explicitly rejected
4. Last known state — what was happening in the final 10–20 exchanges before the conversation died. What was the assistant doing? What was my last instruction? Was a task in progress?
5. Open threads — anything the assistant said it would do next, TODOs, unresolved questions
6. Context to carry over — plugins/connectors used, working folder, any global or folder-level instructions that were active. If the bricked session has memory files under spaces/<...>/memory/, transcribe them — they don't auto-carry to a new session.
Skip noise: don't include full file contents that were read into the transcript, don't include verbose bash output, don't include rendered images or base64 blobs. The goal is a tight document a fresh Cowork session can absorb without re-bricking itself.
## Constraints
- Be efficient with your own context — the source file is huge by definition. Use grep/jq/streaming reads (head, tail, jq -c with filters), not full file loads.
- If you can't parse something, stop and tell me what tool you'd need
- Don't write anything other than HANDOVER.md to disk
Two things that mattered:
The prompt explicitly tells it not to load the transcript into context. My six segment files were 154MB each. A naive Read would have re-bricked the new chat immediately. grep, jq, head, and tail only, never cat or Read on the whole file.
It also tells it to ask before guessing if multiple files match. Mine had a couple of red herrings, background agent heartbeat logs sitting near the real transcript that grep would also pick up.
Lost about ninety minutes thrashing before I tried this.
I hope this helps someone out there.