You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
opencode api truncates large output when stdout is a pipe (un-awaited write before process.exit) #57816
Version: opencode v2.0.32 (source read at that tag); the same write is still on the default branch
(packages/cli/src/commands/handlers/api.ts:46, fetched 2026-10-21).
Reproduce
for i in $(seq 10); do opencode api GET /openapi.json | wc -c; done # 280292 bytes expected
opencode api GET /openapi.json > out.json; wc -c out.json # always 280292
Piped, the count stops at exactly 262144 with exit status 0 in 1 of 8 and 4 of 10 runs (Linux, v2.0.32).
Redirected to a file it is complete every time. The silent exit 0 is what makes it hard to notice.
Cause (v2.0.32)
packages/cli/src/commands/handlers/api.ts:45-46: the handler reads response.text() and calls process.stdout.write(output + ...) once, with no callback and no drain.
packages/cli/src/index.ts:139: Effect.tap(() => Effect.sync(() => process.exit(process.exitCode ?? 0)))
runs right after the handler.
Under Bun a write to a pipe larger than the pipe buffer is asynchronous, so process.exit discards what
the reader has not drained. A write to a file is synchronous, hence complete. 262144 is the pipe buffer
size, not a number in the source.
Suggested fix: wait for the write before exiting, e.g. yield* Effect.promise(() => new Promise<void>((done) => process.stdout.write(out, () => done())))
in the handler, or have the exit tap wait for stdout to drain.
Workaround we use: redirect stdout to a file, never a pipe.
Thanks for the precise write-up, including where in the code it happens. I think this is a duplicate of #52925, which reports the same problem: piped opencode api get output is cut off at 4096-byte multiples (including 262144) with exit status 0, while redirecting to a file gives the complete output. The cause is the same too: the write isn't awaited before process.exit.
Possible duplicates and related issues, ordered by likelihood:
Until that is merged, redirecting to a file (as you already do) is the workaround. The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
Closing this as a duplicate of #52925, as mentioned yesterday. That issue covers the same opencode api truncation when stdout is a pipe: output stops at 4096-byte multiples such as 262144, the exit status is still 0, and redirecting to a file gives the full output. Open PR #52955 makes the handler wait for the stdout write before the CLI exits. Until that lands, redirecting to a file is the workaround. Please follow #52925 for updates. If your problem turns out to be different, reply here and we can reopen.
Activity
opencode-agent commentedon Oct 21, 2026
Thanks for the precise write-up, including where in the code it happens. I think this is a duplicate of #52925, which reports the same problem: piped
opencode api getoutput is cut off at 4096-byte multiples (including 262144) with exit status 0, while redirecting to a file gives the complete output. The cause is the same too: the write isn't awaited beforeprocess.exit.Possible duplicates and related issues, ordered by likelihood:
opencode apitruncation when stdout is a pipe. Open PR fix(cli): flush api output before exit #52955 makes the handler wait for the stdout write before exiting, which is the fix you suggest.session export(PR fix(cli): flush session exports before exit #57347).Until that is merged, redirecting to a file (as you already do) is the workaround. The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
opencode-agent commentedon Oct 22, 2026
Closing this as a duplicate of #52925, as mentioned yesterday. That issue covers the same
opencode apitruncation when stdout is a pipe: output stops at 4096-byte multiples such as 262144, the exit status is still 0, and redirecting to a file gives the full output. Open PR #52955 makes the handler wait for the stdout write before the CLI exits. Until that lands, redirecting to a file is the workaround. Please follow #52925 for updates. If your problem turns out to be different, reply here and we can reopen.