Repository navigation
Bounded thread history bypasses row and byte limits for human turns #24142
Description
Opening a long human-started thread can bypass the configured history limits and freeze the client before the thread becomes visible.
Observed behavior
On a Linux self-hosted 0.1.0 runtime, opening one heavily used thread repeatedly freezes the UI. The runtime carries an unrelated local Codex goal-resume correction. Read-only investigation found 10,626 stored turn-item rows totaling 88,354,121 bytes of JSON; the latest ten human turns account for 10,454 rows and 86,347,649 bytes. These are stored JSON sizes, not measured response sizes. No private transcript or account data is attached.
Source finding, still present in v0.1.2 and main
The latest stable v0.1.2 source and main at 66ee628e0875b2b735b199f42e6151e347833637 still have all three bypasses:
- ProjectionStore.ts: the snapshot query uses
LIMIT -1whenuser_anchorsis nonempty, overridingrowLimitbefore decoding payloads. - threadHistoryPaging.ts: when a human turn exists, row cost becomes zero and only user/raw-turn counts stop collection. The configured 75-item / 1 MiB budgets do not apply.
- ProjectionStore.ts: the history service returns early for
hasUserTurns, bypassing its post-projection byte-budget pass.
A single human turn containing thousands of tool rows therefore defeats the intended bounded initial snapshot and subsequent history pages. Cached oversized snapshots may also make reopening expensive.
Suggested focused reproduction and expected behavior
Create one human turn_start followed by more than 75 command rows, then request a bounded snapshot and page backward through history. Repeat with enough projected output to exceed 1 MiB in fewer than 75 rows.
Ordinary timeline rows should obey the configured row and byte limits even inside a human turn, while older rows remain reachable through cursors. Preserve active control dependencies, interrupt visibility, and progress for individual oversized items. Verify paging returns every source item exactly once.
Related work and limits of the evidence
#21269 and #23315 fix large-thread list layout loops and are valuable update candidates, but do not remove these server-side budget bypasses. #21840 describes writer blocking during snapshot reads; this report identifies the separate unbounded window selection. #22985 concerns reasoning-preview parsing.
The UI symptom was observed on the installed runtime. v0.1.2/main were inspected as source only; no claim is made that a renderer profile proves these bypasses are the sole cause, or that an upgrade has already been tested. An experimental correction with focused regression cases is preserved separately. Its tests have not yet run, and it is not deployed. The immediate update candidate preserves the existing goal-resume repair and does not include this history patch.
Activity
luke2x commentedon Oct 23, 2026
Note
Written by gpt 6.1 sol on behalf of Luke
Opened #24169 for the three budget bypasses, plus the cache rollout needed for existing affected threads. SQL and history selection now apply the existing row/byte limits inside human turns, and the shared thread-cache version changes from 4 to 5 so an old oversized snapshot cannot bypass the fresh bounded load at the same event sequence.
Thanks for the report and experimental investigation. I reviewed that work and credited it in the PR; this implementation was written independently and keeps the client byte parser unchanged.
All 55 history tests and 38 cache/storage/lifecycle tests pass. The before-fix regressions demonstrate the row-limit bypass and cache reuse; the final tests verify exact-once paging, oversized-item progress and a fresh snapshot at the same event sequence. The PR links sanitized logs and discloses that no integrated browser/native scrolling or FPS measurement was performed. Maintainer triage and review are still requested.
TimCrooker commentedon Oct 24, 2026
Independent reproduction on macOS Apple Silicon with desktop
0.1.3-nightly.20261024.3604(build3f3a1bf419f0): this can crash the shared backend and interrupt both Codex and Claude conversations.The desktop logs record 57 backend crashes between 2026-10-24 03:32 and 04:55 UTC. Early crashes explicitly report JavaScript heap exhaustion around 3.6 GB. Later macOS reports show SIGTRAP in the database reader worker during
ValueSerializer::WriteValue,Message::Serialize, andMessagePort::PostMessage.Query start/completion instrumentation, without recording bound values, caught the bounded-history CTE as the outstanding read when a subsequent backend died. It contains
WHEN (SELECT COUNT(*) FROM user_anchors) > 0 THEN -1.Read-only reproduction with the existing 77-row snapshot request and ten-user-turn policy:
These are raw selected-payload sizes, not HTTP response sizes or renderer-memory measurements. The corrected query completed in the actual backend reader worker. Older anchor-based pages remained readable; checks on this thread and two smaller affected threads found only the expected anchor overlap.
A reversible local SQL-only hotfix survived a backend restart, and the worker read succeeded again without runtime interception. No history was deleted and no database repair writes were performed. The full upstream PR has not been installed or tested here.
#24169 removes the exact failing SQL branch and covers the broader history-budget/cache behavior beyond this local hotfix. This adds independent evidence of backend-process failure and interruption across providers. Private databases, transcript contents, thread IDs, and full logs are not attached.
Investigated with GPT-6.1 Sol through the Codex harness in T3 Code, on behalf of the affected user.