bug: TUI session hangs with `InstanceRef not provided` rejection after LSP initialization (v1.15.2)

[ririnto]

Description

In TUI mode, after a tool (e.g., apply_patch) modifies a file, the LSP server initializes and immediately triggers an unhandled InstanceRef not provided rejection. The session appears to hang (stuck at "Preparing patch..." or similar) after this error.

The root cause is in packages/opencode/src/lsp/lsp.ts:294:

Bus.publish(Event.Updated, {})

This static Bus.publish call is made from inside an Effect.promise callback (line 215), where there is no Effect fiber context. Bus.publish internally calls InstanceState.get → InstanceState.context → yield* InstanceRef, which fails because no fiber context is available.

This is the same class of bug as #27829, #27833, #27838, #27857 — Effect.runPromise or equivalent inside Effect.promise losing fiber context. Those were fixed in v1.15.2 (commits 88363f1, 6d2219e) but the lsp.ts call site was missed.

While a targeted fix (providing InstanceRef via .pipe(Effect.provideService(InstanceRef, ctx)) at the call site) would address this specific instance, PR #25694 proposes an infrastructure-level fix at InstanceState.get() that ensures InstanceRef is always propagated into ScopedCache lookups regardless of how the caller provides it. That approach would prevent this entire class of bugs from recurring across any call site that goes through InstanceState.

Log output

INFO  service=permission permission=edit pattern=Sisyphus.md evaluated
INFO  service=format file=Sisyphus.md formatting
INFO  service=bus type=file.edited publishing
INFO  service=lsp file=Sisyphus.md touching file
INFO  service=lsp serverID=remark spawned lsp server
INFO  service=lsp.client serverID=remark sending initialize
INFO  service=lsp.client serverID=remark initialized
ERROR service=default e=InstanceRef not provided rejection

Steps to reproduce

1. Start opencode TUI (opencode)
2. Have a session where the model uses a tool that modifies a file (e.g., apply_patch)
   • This can be a resumed/continued session — the bug is not session-state dependent
   • In my case, it was a .md file being edited
3. After the tool applies changes, the post-edit hook triggers format → LSP touch → LSP spawn
4. Observe InstanceRef not provided rejection in logs (~/.local/share/opencode/log/)
5. The session may hang or become unresponsive after this point

LSP configuration

{
  "lsp": {
    "remark": {
      "command": ["bunx", "--use-system-ca", "remark-language-server", "--stdio"],
      "extensions": [".markdown", ".md"]
    }
  }
}

OpenCode version

1.15.2

Operating System

Linux (WSL2)

Terminal

zsh

[masterkain]

Adding another data point: I can confirm this still happens on OpenCode 1.15.3.

I have three local crash logs from the same flow. Two were on 1.15.1, but the important one was already on 1.15.3: both the parent TUI session and the child subagent session logged version=1.15.3 before the failure.

Sanitized sequence from the 1.15.3 log:

service=session ... version=1.15.3 ... agent=<main agent>
service=session ... version=1.15.3 ... parentID=<parent-session> title=<subagent task>
service=lsp serverID=elixir-ls ... spawned lsp server
service=lsp.client serverID=elixir-ls initialized
ERROR service=default e=InstanceRef not provided rejection
ERROR service=session.processor session.id=<child-session> ... error=Aborted process

This was in TUI/subagent usage, with elixir-ls being initialized after the subagent flow touched project files. So v1.15.3 looks like it fixed the earlier async command / agent generation call sites, but not this LSP-after-initialize path.

[ririnto]

Until Next Release ...

~/.config/opencode/opencode.json

{
    "lsp": false
}

[masterkain]

but I love the smell of lsp in the morning

[CloudSmithBrandon]

Experiencing the same bug with biome and marksman LSPs on opencode-ai v1.15.3 (Windows). Disabling LSPs as workaround. Watching for the fix in PR #25694.

[zentetsukenz]

I have the same issue and tried debug a little bit. This following paragraph is the analysis from Opus 4.7. Could be worthwhile putting into a context for fixing this crashing issue.

Opus 4.7 analysis

Adding another v1.15.1 data point with a different escalation path: same root-cause signature, but in our case it terminates the whole TUI process via Bun SIGTRAP rather than just logging the rejection.

Environment

• opencode 1.15.1 (also reproduced on 1.15.3)
• bundled Bun v1.3.13 (bf2e2cec)
• macOS 26.3.1 (Apple M2)
• terminal: Ghostty / xterm-ghostty
• Reproduced on two separate M2 machines, both running curl-installed opencode
  v1.15.0 does not exhibit this — confirmed by downgrade (opencode upgrade 1.15.0) on both machines.

Trigger

TUI session with an active subagent (Sisyphus - Ultraworker parent → @explore subagent). Pressing Ctrl+X to switch into the running subagent session reliably triggers the chain. On the second occurrence, the parent TUI crashes to terminal with a Bun panic.

Log signature (sanitized, from ~/.local/share/opencode/log/)

INFO  service=session  id=ses_<parent>  version=1.15.1  agent=Sisyphus - Ultraworker  created
INFO  service=session  id=ses_<child>   version=1.15.1  parentID=ses_<parent>  title=Map auth module surface (@explore subagent)  created
...
INFO  service=lsp.client  serverID=elixir-ls  path=/.../lib/.../router.ex     workspace/didChangeWatchedFiles
INFO  service=lsp.client  serverID=elixir-ls  path=/.../lib/.../scope.ex      workspace/didChangeWatchedFiles
ERROR service=default     e=InstanceRef not provided rejection
INFO  service=session.prompt  session.id=ses_<child>   cancel
INFO  service=session.prompt  session.id=ses_<parent>  cancel
INFO  service=lsp.client  serverID=elixir-ls  path=/.../lib/.../user_auth.ex  workspace/didChangeWatchedFiles
ERROR service=session.processor  session.id=ses_<parent>  error=Aborted process
ERROR service=session.processor  session.id=ses_<parent>  error=Aborted process

So this matches the exact path you identified: LSP client initialised → workspace/didChangeWatchedFiles → InstanceRef not provided from inside Bus.publish in lsp.ts. Same call site, elixir-ls instead of remark.

Escalation: process-level SIGTRAP

On the next user input after this rejection, the whole TUI crashes with a Bun panic instead of a clean rejection:

Bun v1.3.13 (bf2e2cec) macOS Silicon
macOS v26.3.1
panic: Segmentation fault at address 0x13D30
SIGTRAP

Stack (from bun.report):

parcel-watcher.node
napi_call_threadsafe_function
ThreadSafeFunction.scheduleDispatch
ConcurrentTask.createFrom

Bun report: https://bun.report/1.3.13/Ma1bf2e2cemxHuhoqC_2+iydmmqhZ_____A2Agz+E
My read on the escalation:

• lsp.ts:294 rejection aborts the session processor mid-flight while @parcel/watcher still holds an NAPI threadsafe function reference back into the Effect runtime.
• The next callback from the native watcher thread fires napi_call_threadsafe_function into a callback whose surrounding Effect scope has been torn down, dereferencing freed memory inside Bun's ConcurrentTask.createFrom.
• This is consistent with the NAPI deferred-finalizer bug class Bun fixed in 1.3.14 (release notes). opencode bundles 1.3.13, so the underlying NAPI race is latent — v1.15.0 happens to avoid tripping it; the v1.15.1 InstanceRef rejection path appears to trip it on subagent transition.
  The parcel-watcher callback site in packages/opencode/src/file/watcher.ts also changed in v1.15.1 (InstanceState.bind → EffectBridge.make().bind), which is the other call site I'd suspect of dangling-callback-after-scope-end. Worth checking whether the bridge finalizer can run while parcel's native thread still has the callback pointer in flight.

Why this is a separate failure mode worth tracking

The "rejection + hang" surface you described in the OP is bad UX but recoverable. The variant I'm seeing crashes the entire bun process, taking the parent TUI and any running subagents down with it — auth/session state survives, but mid-flight work is lost and there is no .ips dump (process exits via SIGTRAP without handing off to Apple CrashReporter).
Happy to file this as a separate issue specifically targeting the SIGTRAP escalation if that's preferable to keeping it bundled here. Either way, the infrastructure-level fix in InstanceState.get() (PR #25694) plus auditing remaining Effect.promise callsites that call InstanceState-backed APIs (notably packages/opencode/src/file/watcher.ts) would close both surfaces.