Threads remain stuck on “Loading messages…” after disk space is freed

What happened

When the disk fills up, some threads in the desktop app stop loading and show “Loading messages…” indefinitely. Other threads still work.

Freeing disk space does not recover the affected threads. Restarting T3 Code has restored access in previous occurrences, but restarting interrupts ongoing work. The current occurrence was investigated after freeing space and before restarting.

Expected behavior: show an actionable storage error and recover after space becomes available.

Diagnosis

Root cause remains unconfirmed.

Read-only investigation found:

• The existing server process remained alive and answered its root HTTP endpoint.
• Both an affected thread and a working thread had readable SQLite records, ready Codex sessions, and no recorded session error.
• The affected thread contained 61 messages and 1,066 activity records. Its message attachment and activity JSON parsed successfully.
• Retained server and desktop traces contained no explicit ENOSPC or SQLITE_FULL errors.
• In v0.0.38, apps/web/src/threadSync.ts displays this loading banner when a thread shell exists but its detail data has not loaded.

A direct snapshot request without authentication returned HTTP 401, so it did not test the affected snapshot. Main-app DevTools could not be opened during triage; client console and network evidence are unavailable. These checks do not rule out runtime database or client state failures.

Steps to reproduce

User-observed sequence; no deterministic reproduction established:

1. Use T3 Code desktop while the filesystem runs out of space.
2. Open threads. Some remain on “Loading messages…”, while others work.
3. Free disk space.
4. Affected threads remain stuck.
5. Restart T3 Code to restore access, as observed in previous occurrences.

Version

0.0.38, source inspected at tag v0.0.38.

Environment

Linux x64, kernel 6.8.0-138-generic; desktop app with local server. Triage runtime: Node v22.22.0.

Evidence

Screenshot shows an empty conversation with the persistent loading banner. After cleanup, the home filesystem had approximately 26 GB available.

Related issues

PR #5104 describes SQLite I/O failures requiring restart, but was not merged. Issue #10206 describes the same loading symptom from client decoding failures. Neither is a confirmed duplicate.

Fix applied or workaround

No changes, database writes, or restarts were performed during triage. Freeing space alone did not help. Restarting has helped previously.

Filed by

Codex, GPT-6, via t3 triage.

Screenshot

Start with apps/web/src/threadSync.ts and compare the loading path with Issue #10206 and PR #5104. Investigate the affected and working thread state around the local server and SQLite records, then validate a fix against the disk-full sequence; done means an actionable storage error and recovery after space is freed without restarting T3 Code.