Summary
Two related failure modes were observed on gjc 0.13.2 (Windows 11, user profile wj-balanced, chain openai-codex/gpt-5.6-sol:low -> opencode-go/kimi-k3 -> opencode-go/kimi-k2.6):
-
Error: Managed fallback attempt exceeded the provisional event buffer limit — already root-caused in a local lesson note (lessons/gjc_managed_fallback_buffer_overflow.md): GJC's packages/agent/src/agent-loop.ts stages the current provider attempt's streaming events in a provisional transaction (10,000 events / 16 MiB). Overflowing it raises ManagedAttemptBufferOverflowError, a local non-retryable error with no transport facts, surfaced directly to the user instead of advancing the fallback chain.
-
Error: Codex websocket transport error: websocket request already in progress — new report: after a turn is aborted (e.g. by the buffer overflow above or by turn-aborted), the Codex websocket transport appears to keep the previous request in an "in progress" state. Subsequent requests then fail with websocket request already in progress, and the managed fallback attempt that follows can itself exceed the provisional event buffer limit, producing the chained error sequence:
Error: Managed fallback attempt exceeded the provisional event buffer limit
Error: Codex websocket transport error: websocket request already in progress
Error: Codex websocket transport error: websocket request already in progress
Reproduction context
Session where this chained failure repeated across multiple turns: D:/LLM_WIKI wiki workspace, 2026-08-14. Triggering pattern each time:
- Agent loads large web documentation pages via the
read tool (e.g. Wiki.js docs pages that fail reader-mode conversion and return full raw HTML; one page exceeded ~10 KiB raw HTML with embedded base64).
- Final response generation overflows the provisional event buffer ->
ManagedAttemptBufferOverflowError, turn aborted (input=0, output=0, stopReason=error in the session JSONL).
- Next user message hits
websocket request already in progress — the aborted turn's websocket request was never cleaned up.
- The managed fallback attempt for that wedged request then overflows the buffer again, producing the full three-error sequence above.
Expected behavior
- When a turn is aborted (buffer overflow, user abort, or transport failure), the Codex websocket transport should release/reset the in-flight request so the next user message starts cleanly.
ManagedAttemptBufferOverflowError should either advance the fallback chain or at minimum not poison the transport for subsequent turns.
Actual behavior
- The websocket transport keeps the previous request "in progress" after abort; every subsequent request fails with
websocket request already in progress until the session is restarted.
- The fallback attempt for the wedged request re-overflows the buffer, compounding the failure instead of recovering.
Environment
- gjc
0.13.2 (official updater fallback binary, SHA-256 4f3f1cc634c437b21aac60f8d60900618062e50a3a7a189a29205e5d203b8d38)
- Windows 11 Pro (10.0.26200), AMD Ryzen 7 9700X
- Terminal: Orca 1.4.179
- Config:
modelProfile.default=wj-balanced, defaultThinkingLevel=low; gjc config doctor --json -> valid=true, issues=[]
Related issues
Workaround
Wait several seconds after an aborted turn before sending the next message; if the websocket error persists, fully restart the gjc session. Avoid loading large raw-HTML pages in a single turn.
Summary
Two related failure modes were observed on gjc
0.13.2(Windows 11, user profilewj-balanced, chainopenai-codex/gpt-5.6-sol:low->opencode-go/kimi-k3->opencode-go/kimi-k2.6):Error: Managed fallback attempt exceeded the provisional event buffer limit— already root-caused in a local lesson note (lessons/gjc_managed_fallback_buffer_overflow.md): GJC'spackages/agent/src/agent-loop.tsstages the current provider attempt's streaming events in a provisional transaction (10,000 events / 16 MiB). Overflowing it raisesManagedAttemptBufferOverflowError, a local non-retryable error with no transport facts, surfaced directly to the user instead of advancing the fallback chain.Error: Codex websocket transport error: websocket request already in progress— new report: after a turn is aborted (e.g. by the buffer overflow above or byturn-aborted), the Codex websocket transport appears to keep the previous request in an "in progress" state. Subsequent requests then fail withwebsocket request already in progress, and the managed fallback attempt that follows can itself exceed the provisional event buffer limit, producing the chained error sequence:Reproduction context
Session where this chained failure repeated across multiple turns:
D:/LLM_WIKIwiki workspace, 2026-08-14. Triggering pattern each time:readtool (e.g. Wiki.js docs pages that fail reader-mode conversion and return full raw HTML; one page exceeded ~10 KiB raw HTML with embedded base64).ManagedAttemptBufferOverflowError, turn aborted (input=0,output=0,stopReason=errorin the session JSONL).websocket request already in progress— the aborted turn's websocket request was never cleaned up.Expected behavior
ManagedAttemptBufferOverflowErrorshould either advance the fallback chain or at minimum not poison the transport for subsequent turns.Actual behavior
websocket request already in progressuntil the session is restarted.Environment
0.13.2(official updater fallback binary, SHA-2564f3f1cc634c437b21aac60f8d60900618062e50a3a7a189a29205e5d203b8d38)modelProfile.default=wj-balanced,defaultThinkingLevel=low;gjc config doctor --json->valid=true,issues=[]Related issues
Workaround
Wait several seconds after an aborted turn before sending the next message; if the websocket error persists, fully restart the gjc session. Avoid loading large raw-HTML pages in a single turn.