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