Skip to content

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

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

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

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions