Skip to content

v1.14.26: second TUI in same project directory fails with setRawMode errno 9 / EIO #24557

@sayefiqbal

Description

@sayefiqbal

Description

Summary

Starting in v1.14.26, launching a second opencode TUI in the same project directory (e.g. a new terminal tab cd'd into the same repo) fails silently — the new TUI never renders. The first TUI continues to work.
v1.14.25 and earlier allowed multiple TUIs against the same directory.

Environment

  • opencode: v1.14.26 (installed via curl installer)
  • OS: macOS (darwin, arm64)
  • Terminal: Terminal.app / zsh, multiple tabs
  • Project: standard git repo, no worktrees

Steps to reproduce

Expected behavior

Either:

  • Both TUIs run concurrently against the same project (prior behavior), or
  • The second TUI shows a clear error message explaining that another instance is already attached and how to resolve it (attach, use worktree, etc.).

Actual behavior

Silent failure. Log shows the server-proxy worker attempting to bootstrap, then shutting down immediately after setRawMode fails with errno 9 (EBADF):

INFO service=server-proxy directory=/path/to/project creating instance
ERROR service=server-proxy e=setRawMode failed with errno: 9 exception
ERROR service=server-proxy error=setRawMode failed with errno: 9 process error
ERROR service=server-proxy e=EIO: i/o error, read exception
INFO service=project directory=/path/to/project fromDirectory
INFO service=server-proxy worker shutting down
INFO service=server-proxy disposing all instances
ERROR service=models.dev error=Refusing to release: lock is compromised (metadata missing). Failed to fetch models.dev

The failing process stays alive in S state (detached from TTY) and holds open fds on opencode.db, requiring kill -9 to clean up.

Suspected cause

The pty/TUI-bridging work that landed in v1.14.26 — particularly:

setRawMode lives on the stdin TTY; the new server-proxy layer appears to be taking stdin handoff for the already-attached instance and re-calling setRawMode on a closed/dup'd fd.

Workarounds

  • Use a separate git worktree per tab (distinct cwd → distinct server-proxy instance works fine).
  • Downgrade to v1.14.25 (opencode upgrade 1.14.25).

Additional info

Side effect: the first instance's snapshot gc occasionally fails with Another git process seems to be running in this repository because the stale server-proxy workers hold partial git locks:

WARN service=snapshot exitCode=128 stderr=fatal: Unable to create
'$HOME/.local/share/opencode/snapshot/.../gc.pid.lock': File exists.

Plugins

No response

OpenCode version

1.14.26

Steps to reproduce

  1. In tab A: cd ~/some/project && opencode → TUI opens normally.
  2. In tab B: cd ~/some/project && opencode → TUI briefly appears to start, then exits or hangs without rendering.

Screenshot and/or share link

No response

Operating System

No response

Terminal

H

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingcoreAnything pertaining to core functionality of the application (opencode server stuff)

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions