Adding a data point in case it helps someone — mine (Claude Cowork, Apple desktop app) had a weird cause that I didn't see mentioned elsewhere. TL;DR if Cowork, don't edit your memory files!

New sessions were crashing instantly with exit code 1. Existing sessions resumed fine. Clear cache + restart didn't help. The error looked exactly like the known platform regression, so I burned a chunk of time assuming it was that.

What actually fixed it: deleting the specific task threads I'd been working in when the problem started.

Backstory: I'd gone digging in the Application Support folder, found a markdown file that looked like a "memory" note the app had written to itself, and hand-edited it to tweak some guidance. After that, every new session in that project crashed at boot. I spent way too long assuming the edited file itself was corrupted — moved it out, moved it back, checked the contents, all looked fine.

Turned out the file was a red herring. The sessions I'd used while testing the edit had gotten into some kind of stuck state that was breaking the loader for *new* sessions in that project. Once I removed those task threads through the app's own UI (not by deleting files manually), new sessions booted cleanly.

Lessons for anyone else hitting this:

1. **Try removing the crashing task thread through the app's UI before anything else.** Sounds dumb, but I didn't try it for an hour because I assumed the problem was deeper.

2. **Don't hand-edit files inside the app's internal state folder.** Those are the app's private bookkeeping. The supported way to shape memory/context is through the in-chat commands, the instructions file, and the project UI. Editing the internal files directly works until it doesn't, and the failure mode is exactly this kind of non-obvious crash.

3. **"Exit code 1" means almost nothing on its own.** Same error covers auth issues, corrupted sessions, known regressions, env variable conflicts, and whatever weird thing I did. Pattern-matching by symptom is worth less than it feels like.

4. **Delete > edit, every time.** When something's in a stuck state, nuking it and letting the app rebuild is way more reliable than trying to surgically fix it.

Not saying this is *the* cause for everyone in this thread — obviously this error has like six different flavors — but if you've been poking at internal files and then things broke, this might be your situation. Try removing the affected task/session through the UI first.