Repository navigation
Background hook stderr output can be painted into the input box until terminal repaint #31219
Description
Describe the bug
pic 1
pic 2
Sometimes background hook/plugin output is rendered inside the OpenCode input area (or bottom status/input region) instead of appearing in the normal terminal flow.
In my case this happens with a local memory hook that writes status lines to stderr. The visible symptom is that a line like:
[memory] extract done ...
or
[memory] compact: store already clean ...
shows up where the input box is, making the UI look corrupted.
The display becomes normal again immediately if I:
- resize the terminal window
- trigger a popup with
Ctrl+K
That makes this look like a repaint / cursor-placement bug rather than the hook actually writing into the prompt buffer.
Investigation
In my local setup, the background memory plugin logs via console.error(...), so the hook is writing to stderr.
That seems to suggest the issue is: when background stderr arrives while the OpenCode TUI is idle or waiting for input, the line can be painted into the input/status region until the next full redraw.
To reproduce
I do not yet have a minimal standalone repro, but the rough pattern is:
- Run OpenCode in the VSCode integrated terminal
- Have a background hook/plugin that emits status lines to
stderr - Wait until the hook fires while OpenCode is sitting at the input screen
- The hook output may appear inside the input area / bottom UI region
- Resize the terminal window or trigger
Ctrl+K - The UI redraws and looks normal again
Expected behavior
Background hook output should not corrupt the input box or bottom UI region. If stderr output is allowed, OpenCode should preserve cursor placement and repaint correctly.
Actual behavior
A background hook status line is sometimes drawn into the input box / lower UI area until a repaint happens.
Environment
- OpenCode: 1.16.2
- Terminal: VSCode integrated terminal
- OS: macOS
Activity
hcsum commentedon Jun 7, 2026
in fact stdin also shows
iclawos commentedon Jun 25, 2026
Description
Two red error messages appear persistently in the command input area (the text box where you type), not in a log or status panel:
gbrain save failedshellerror: failed with exit code 1Expected behavior: MCP server errors should be handled silently or displayed in a dedicated status/log area, not injected into the command input widget.
Actual behavior: Red error text appears inside the command input area, interfering with typing. The stderr from the gbrain MCP subprocess is being rendered in the wrong UI widget.
Plugins
@nntoan/gstack
OpenCode version
Latest (via npx opencode + @nntoan/gstack plugin)
Steps to reproduce
Restart opencode
Red error messages appear in command input area
Screenshot and/or share link
N/A
Operating System
Linux Mint 22 (Ubuntu 24.04 base)
Terminal
GNOME Terminal
konard commentedon Jul 23, 2026
I can confirm this on OpenCode 1.18.4 on Linux with a second process writing to the same PTY. This is not limited to plugin or MCP output.
In our reproducible case, a wrapper started a local HTTP server and then launched OpenCode in the foreground. The server inherited the wrapper's
stdout/stderr. When OpenCode made a model request, the sibling server printed a request trace (including JSON) tostderr; those bytes were painted over the active OpenCode TUI. Resizing the terminal immediately restored the correct frame. Screenshots of the corrupted frame and resize repaint are in link-assistant/formal-ai#819.The core process shape was:
Our application-level fix is to redirect the background server's
stdoutandstderrto a durable log before launching OpenCode. A PTY regression now verifies that a unique request-body marker never reaches the terminal stream. That fully prevents the corruption in our wrapper, but OpenCode still appears vulnerable to any unrelated process that retains the same terminal descriptors.Expected defensive behavior: if external terminal output arrives while the fullscreen renderer owns the terminal, perform a complete redraw (or otherwise restore cursor/frame state) so the bytes cannot remain inside the input/status region.
github-actions commentedon Sep 23, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.