Repository navigation
Conversation
…unnable PersistentPty.available was `process.platform !== "win32"`, so any build without a runnable opencode-pty binary still reported `capabilities.persistentPty: true`. A platform with no @opencode-ai/pty package, or a build that did not embed the binary and has no `opencode-pty` on $PATH, therefore offered persistent terminals in the client while every create failed with HTTP 503 and a misleading "Unable to load terminal" (the server log only showed "Executable not found in $PATH: \"opencode-pty\""). Report availability only when a daemon can actually be resolved: an embedded asset, OPENCODE_PTY_BIN, or `opencode-pty` on $PATH.
github-actions
Bot
added
the
needs:compliance
|
The following comment was made by an LLM, it may be inaccurate: |
The TUI's persistent terminals are backed by a separate opencode-pty daemon
(Rust, linking Ghostty's VT parser). Upstream ships no FreeBSD build and
@opencode-ai/pty has no freebsd package, so creating a terminal failed with
HTTP 503 ("Unable to load terminal"): the client spawned `opencode-pty` from
$PATH and found nothing.
Build it from source, pinned to the @opencode-ai/pty release (and its
ghostty-revision), and embed it into the executable through OPENCODE_PTY_BIN.
The Ghostty Zig dependencies are warmed into an offline cache at fetch time,
like the existing bun and WebAssembly caches, so the build stays offline.
See files/opencode-pty-build.rs.patch and files/ghostty-zig-0.16-std.patch.
Also enable OpenTUI's Ghostty VT backed embedded terminal, which the client
uses to render terminal panes. OpenTUI only builds it for linux/macos/windows
and otherwise installs a stub whose createEmbeddedTerminal() reports
"embedded terminal support is unavailable", which crashed the TUI as soon as
a terminal pane opened. See files/opentui-ghostty-vt-freebsd.patch.
Reported upstream as:
- opencode: anomalyco/opencode#54583
- opentui: anomalyco/opentui#1445
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
The fix works. With the PTY binding mocked as missing, no OPENCODE_PTY_BIN and no opencode-pty on $PATH, PersistentPty.available is true on the base and false with this PR. In the normal Linux dev setup the embedded binary still resolves, so available stays true and supported builds are unchanged. The existing persistent-PTY tests in packages/core and packages/server and the packages/core typecheck pass.
Public API: no schema change. Only the value of capabilities.persistentPty is now accurate; clients already gate on it.
The check still can't tell when a binary is found but can't run (e.g. the old-glibc case in #51796), so that issue stays open. binary.node.ts keeps the platform-only check, as you noted; not blocking.
Related: #51796
github-actions
Bot
removed
the
needs:compliance
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
|
@neriousy - may I kindly ask you to review? |
|
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:
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. |
|
I have a feeling that its impossible to contribute to the project |
Issue for this PR
Closes #
Related: #51796
Type of change
What does this PR do?
PersistentPty.availableisprocess.platform !== "win32", and the server reports it ascapabilities.persistentPty(packages/server/src/handlers/server.ts). A build with no runnableopencode-ptydaemon therefore still advertises persistent terminals: the client offers them, and every create fails with HTTP 503 (only "Unable to load terminal" in the TUI), while the server log saysExecutable not found in $PATH: "opencode-pty".This changes
packages/core/src/persistent-pty/binary.bun.tsso availability also requires the daemon to be resolvable — an embedded asset,OPENCODE_PTY_BIN, oropencode-ptyon$PATH.No schema change, so no client/OpenAPI regeneration is needed.
binary.node.tshas the same platform-only assumption but noBun.which; I left it alone to keep this focused.How did you verify your code works?
Ran the exact predicate with Bun on FreeBSD under each condition:
opencode-ptyon PATHAlso the real case this comes from: a FreeBSD build that embeds the daemon via
OPENCODE_PTY_BINreportscapabilities.persistentPty: trueand creates terminals without a 503.Screenshots / recordings
N/A, no UI change.
Checklist
Added by the opencode bot (AI-generated).
Related: #51796