fix(tui): contain stray stdio writes - #43065

Scope note: this guards the JavaScript process.stdout/stderr.write wrappers, so it contains writes from plugins, the worker's server logging, and --print-logs.

It does not contain writes made by native code straight to the file descriptor — e.g. the ALSA diagnostics block in #41763 / #41770. Same class of bug, but that needs fd-level redirection (dup2), not a JS wrapper.

The same mechanism is what makes this safe: opentui writes frames natively, so frame output never passes through these wrappers. Verified — a guard installed before createCliRenderer captured zero frame bytes while rendering stayed correct.

AI code review — automated review for reference; please use your judgment.

• packages/tui/src/util/stdio-guard.ts:47 — fchmodSync and fstatSync run OUTSIDE the try/catch protecting openSync, so a log directory whose filesystem rejects permission changes (FAT/exfat mounts, some network shares) throws during worker.ts module initialization and kills the entire TUI backend before it starts — move the post-open syscalls into the same guarded block with the existing blackhole-guard fallback, and add a test simulating the chmod failure path.
• packages/tui/src/util/stdio-guard.ts:53 — content.subarray(0, remaining) can slice through a multi-byte UTF-8 sequence, leaving a corrupted final character at the cap boundary; trimming to the last complete codepoint is cheap and keeps the containment logs greppable.
• packages/tui/src/util/stdio-guard.ts:27 — The wrapper unconditionally returns true, suppressing the backpressure signal real streams give when their buffer is full; libraries that throttle on the return value will happily flood a slow file sink — worth at least a comment documenting that suppression as intentional for the TUI lifetime.
• packages/tui/test/util/stdio-guard.test.ts:150 — Excellent breadth (sentinel isolation, both callback positions, throwing sinks, truncation math); one missing pair: interleaved stdout/stderr ordering across the two wrapped streams should be preserved in the file, and the worker.ts module-scope installation should have a smoke assertion that importing the worker doesn't throw when Global.Path.log is unwritable — that is exactly the crash class the first finding describes.

— AI code review (automated)

AI code review — automated review for reference; please use your judgment.

• packages/tui/src/util/stdio-guard.ts — well-built primitive: exact-original restoration, callback handling in both argument positions, sink isolation via try/catch, 0600 perms enforced post-open (umask-proof), and a hard byte cap so a chatty plugin can't fill the disk.
• packages/tui/src/app.tsx:194 — smart placement detail in the comment: releasing the guard before the fatal-error print means crash output still reaches a restored stderr. Worth keeping that invariant in mind if scope structure changes.
• Nit: two concurrent opencode instances share stdio-main.log with truncate: true, so instance B startup wipes instance A's captured output. A pid-suffixed filename would avoid the clobbering.
• packages/opencode/src/cli/tui/worker.ts:14 — worker realm gets its own log file, good separation; if rpc.dispose never runs (hard crash) the fd stays open until process exit, which is fine but worth knowing.
• Test suite covers the failure modes I'd worry about (throwing sink, unopenable file, limit accounting across installs) — excellent coverage.

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.