fix(cli): flush api output before exit - #52955

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

The following comment was made by an LLM, it may be inaccurate:

Independently checked abe4fed299 with the real V2 CLI on macOS arm64 / Bun 1.4.2 and a local HTTP fixture. All 600,095 bytes (including the newline) arrived intact through file redirection, a fast pipe, and a reader consuming 4 KiB every 5 ms; each exited 0. The same fixture previously truncated on both pipe readers.

A 503 response also delivered the complete body through all three readers and retained exit 1 plus the HTTP diagnostic. Closing the helper's pipe after 4 KiB exited 0 without stderr. The five stdio / API-resolution tests pass. This is local synthetic validation; I have not checked Linux or Windows.

Thanks for the independent verification, @r266-tech! I've rebased onto the latest v2 (no code changes). The logic is identical to abe4fed299.

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

This still addresses the API pipe-truncation reports in #60395 and #60231. Please consider reopening it rather than starting a duplicate implementation.

Linux/Bun 1.4.4 synthetic validation of this implementation in an integration branch delivered the complete JSON through a real OS pipe, with matching byte count and SHA-256. The unpatched writer truncated the same response despite exiting 0. This is scoped pipe validation, not a claim that the entire upstream suite passed.

One behavior is worth reconsidering: writeStdout resolves on EPIPE. That is convenient for | head, but lets incomplete structured output look successful to callers that inspect the writer's exit status. For API output used as an archive, rejecting the write error is safer:

if (error) return reject(error);
resolve();

The regression can avoid sleeps: spawn a writer blocked on stdin, close its stdout reader, then release stdin. Handle the stream's error event in the fixture so the assertion checks the helper's rejection rather than an incidental unhandled event. The writer should reject with EPIPE and exit nonzero. The existing complete-output pipe test should continue to pass.

A tested follow-up preserving this PR's original history is available at matt8s@99e7f1c. The two changed blobs match the successful Linux integration validation, including full Core/CLI tests and compiler checks. No separate duplicate implementation PR was opened.