Streaming text duplicates and code-edit turns can stall before fileChange events under opencodex

Summary

I am seeing two symptoms after switching Codex to the opencodex provider path. I did not see this behavior when using native GPT/Codex without opencodex.

This is separate from #17. #17 is about mobile-created routed-model threads failing ChatGPT account model validation. This issue is about streaming/event stability after a thread is already running through the local opencodex setup.

Environment

OS: Windows 11
opencodex proxy: local, http://localhost:10100
/healthz version: 2.1.3
Codex app account mode: ChatGPT account
Codex provider config: opencodex injected as default provider
Models observed:
- gpt-5.5 pass-through via the opencodex provider path
- routed models such as umans/umans-kimi-k2.7
Mobile app was used to observe and send follow-up prompts to local laptop threads.

Symptom 1: live streaming text duplicates partial chunks

While a turn is streaming on mobile, the visible text sometimes duplicates pieces of words or chunks, for example:

좋좋아아
op opencencodexodex
GitGitHubHub
issue issue

After the turn finishes, the final stored message is corrected and appears normal in the thread history. So this looks like a live streaming delta/rendering issue rather than permanent message corruption.

Symptom 2: code-edit turns can stall after commentary, before fileChange

In a delegated code-edit thread, the agent reached the point where it said it was about to edit files, for example:

수정 들어간다. `rust-cargo-lock.ts`에 ... 넣고 ...

But the turn produced no fileChange event and no actual code edit. The thread later showed a top-level systemError state even though the individual turn summary looked partially completed.

When I sent a much smaller recovery prompt to the same thread, asking for only one tiny file change, the next turn successfully emitted a fileChange event and completed.

That makes the failure look like it happens around the transition from streamed assistant commentary into tool/file-change events, especially after context compaction or in large WIP code sessions.

Why I suspect the opencodex path

The key clue is that I did not see this behavior when using native GPT/Codex directly. The symptoms started after routing Codex through opencodex. Even OpenAI models such as gpt-5.5 may still be going through the opencodex provider/proxy path in this setup.

I do not know whether the root cause is in opencodex's Responses/SSE translation, Codex app remote-thread handling, or an interaction between both. But the visible behavior suggests that the streaming/tool event contract may not be perfectly matching what Codex expects.

Expected behavior

Live streaming should not duplicate partial chunks.
If a turn reaches the file-edit phase, it should either emit the expected fileChange event or fail with a clear error.
Context compaction should not leave the thread in a state where the agent only emits commentary and silently stops before the actual edit.

Current workaround

Keep opencodex code-edit turns very small.
Treat commentary such as “수정 들어간다” as not enough; verify that a fileChange event actually appears.
After context compaction, send a small recovery prompt that asks for only one file or one test chunk.
For large WIP code edits, native GPT/Codex still appears more reliable.

Additional exact Codex App error from the failed code-edit turn:

stream disconnected before completion: stream closed before response.completed

This appeared after the assistant had already streamed commentary saying it was about to edit files, but before any fileChange event was emitted. The Codex App UI showed reconnect attempts up to 5/5, then the turn failed.

A later smaller retry in the same thread succeeded and emitted a fileChange event. That makes the failure look specifically tied to the Responses stream closing without the terminal response.completed event around the commentary -> tool/fileChange transition.

Additional runtime note from the local Windows repro/debugging setup:

The proxy instability was also accompanied by native Bun crashes on the current stable Bun release I was using (1.3.14, latest stable release shown by GitHub at the time I checked). The crash is a Bun-level segmentation fault, not a normal JS exception from opencodex.

I filed that separately upstream: oven-sh/bun#32585

Local evidence:

Args: "C:\Users\cherr\.bun\bin\bun.exe" "run" "src/cli.ts" "start"
Features: abort_signal(5) fetch(6) http_server jsc transpiler_cache(2) tsconfig
Elapsed: 61275ms | User: 1453ms | Sys: 765ms
RSS: 114.54MB | Peak: 0.15GB | Commit: 0.37GB | Faults: 54893 | Machine: 33.65GB

panic(main thread): Segmentation fault at address 0xFFFFFFFFFFFFFFFF
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Another run reported a much higher peak before crashing:

Elapsed: 291839ms | User: 30687ms | Sys: 31796ms
RSS: 0.15GB | Peak: 12.13GB | Commit: 0.47GB | Faults: 11397952 | Machine: 33.65GB

For now my local watchdog prefers C:\Users\cherr\.bun-canary\bin\bun.exe when present (1.4.0 in my environment) and falls back to stable Bun. I would treat this only as a local workaround/debugging note, not as a recommendation for opencodex to depend on canary Bun by default.

Update from the provider-side investigation:

I added a first-class Umans AI Coding Plan preset on dev using the Anthropic Messages wire format, not the OpenAI Chat Completions path.

The configured provider shape is now:

{
  "adapter": "anthropic",
  "baseUrl": "https://api.code.umans.ai",
  "authMode": "key",
  "defaultModel": "umans-coder"
}

Runtime behavior covered by tests:

requests go to POST https://api.code.umans.ai/v1/messages
auth uses x-api-key, not Authorization: Bearer
anthropic-version: 2023-06-01 is sent
Umans tool-name compatibility is enabled with a separate ocx_ wire prefix and stripped before tool calls are returned to Codex
CLI/API-key login preserves Umans runtime metadata when saving the provider

Relevant commits on dev:

f4b270b — feat: add Umans provider preset
0a3a7f7 — chore: trim umans devlog whitespace

I cannot run a live end-to-end Umans verification myself because I do not currently have an active Umans subscription/API key. Keeping this issue open for now. If anyone with Umans access can test the new preset and report whether the streaming duplication / commentary-before-fileChange stall still reproduces on the Anthropic Messages path, that feedback would decide whether this issue can be closed or whether we need to continue investigating the Responses/SSE bridge separately.

Tested the new dev Umans preset with an active Umans key.

Local setup used for this test:

opencodex: upstream/dev at c2c36d2 (healthz version 2.1.6)
provider: umans
adapter: anthropic
baseUrl: https://api.code.umans.ai
model tested: umans/umans-glm-5.2
runtime: Bun canary 1.4.0 on Windows 11

Results:

Direct non-streaming /v1/responses smoke succeeded.

model: umans-glm-5.2
status: completed
output text: OCX_OK
usage: input_tokens=19, output_tokens=24, total_tokens=43

Direct streaming /v1/responses smoke also succeeded and emitted the terminal event correctly.

has response.completed: true
has response.failed: false
has response.incomplete: false
output text: STREAM_OK
final events included response.output_text.done, response.output_item.done, response.completed, then [DONE]

Codex App background-thread file-change smoke with umans/umans-glm-5.2 succeeded twice:

turn 1 created a scratch file and emitted a completed fileChange add event
turn 2 updated the same scratch file and emitted a completed fileChange update event
both turns completed without the previous stream closed before response.completed failure
I did not observe duplicated streamed text in these two smoke turns

So at least for a small file-edit workflow, the new Umans Anthropic Messages path did not reproduce the commentary-before-fileChange stall. This is not yet a heavy/stress reproduction, but it is a positive live E2E result for umans/umans-glm-5.2 on the new preset.

Thanks for testing this with an active Umans key. This is a useful positive signal.

What this confirms so far:

the new umans preset is actually usable with the Anthropic Messages path
direct non-streaming /v1/responses completes
direct streaming /v1/responses emits response.completed and [DONE]
small Codex App background-thread file-change turns complete and emit fileChange
the previous commentary-before-fileChange stall did not reproduce in those two smoke turns
duplicated live text was not observed in those smoke turns

I will keep this issue open for now because the original report involved larger/WIP code-edit turns and context-heavy sessions, and this first verification was intentionally a small smoke test.

Suggested close criteria:

run one heavier routed Umans code-edit turn that creates/updates multiple files or runs after a larger context thread
confirm the stream still reaches response.completed
confirm the Codex App receives the expected fileChange events
confirm no visible duplicated streaming text during the turn

If those hold, I think we can close the Umans-provider-protocol part as fixed by the Anthropic Messages preset. If the issue still reproduces under heavier load, the next investigation should move away from the Umans provider config and toward the generic Responses/SSE bridge, terminal event handling, or the Windows/Bun runtime crash path noted above.

Closing this based on the positive live Umans smoke result on the new Anthropic Messages preset.

The fix is on dev and will be included in the upcoming main merge / release. If this or a related streaming/fileChange problem reappears after the release, please open a fresh issue with the new logs and reproduction details so we can track it separately from the original Umans provider-protocol mismatch.

fix(devin): report the context windows Cognition actually serves (#4323)

fix(devin): replay the assistant's reasoning instead of dropping it (#…

fix(devin): preserve the catalog image-support flag as a tri-state (#…

fix(devin): report the context windows Cognition actually serves (lid…

fix(devin): replay the assistant's reasoning instead of dropping it (l…

fix(devin): preserve the catalog image-support flag as a tri-state (l…

fix(devin): never replay a Claude signature, and pin the signature-on…

fix(devin): carry reasoning signatures across turns

fix(devin): never replay a Claude signature, and pin the signature-on…

fix(devin): carry reasoning signatures across turns

fix(devin): never replay a Claude signature, and pin the signature-on…

fix(devin): carry reasoning signatures across turns

fix(devin): never replay a Claude signature, and pin the signature-on…

fix(devin): carry reasoning signatures across turns (carry #6116) (#6184

Navigation Menu

Repository navigation

Streaming text duplicates and code-edit turns can stall before fileChange events under opencodex #18

Summary

Environment

Symptom 1: live streaming text duplicates partial chunks

Symptom 2: code-edit turns can stall after commentary, before fileChange

Why I suspect the opencodex path

Expected behavior

Current workaround

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Streaming text duplicates and code-edit turns can stall before fileChange events under opencodex #18

Description

Summary

Environment

Symptom 1: live streaming text duplicates partial chunks

Symptom 2: code-edit turns can stall after commentary, before fileChange

Why I suspect the opencodex path

Expected behavior

Current workaround

Activity

0disoft commented on Jun 22, 2026

0disoft commented on Jun 22, 2026

lidge-jun commented on Jun 22, 2026

0disoft commented on Jun 22, 2026

lidge-jun commented on Jun 22, 2026

lidge-jun commented on Jun 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions