Skip to content

[Bug]: LSP sidebar shows 'will activate as files are read' even after files are read and edited by orchestrator #398

@alvinreal

Description

@alvinreal

What happened, and what did you expect?

What happened:
When using the OpenCode TUI with the orchestrator agent, the LSP sidebar continues to display "LSPs will activate as files are read" even after the orchestrator has read and edited multiple files in the project.

Expected behavior:
The LSP sidebar should update to show the connected LSP servers once files are read, and should reflect the actual LSP status when files are being edited.

Steps to reproduce

  1. Open a project in OpenCode TUI with LSP support enabled
  2. Use an orchestrator agent that reads files (e.g., via the read tool)
  3. Observe that files are being read and edited
  4. Check the LSP sidebar - it still shows "LSPs will activate as files are read" even though files have been processed

Root Cause Analysis

After investigating the code, I found the issue is in how LSP activation is triggered:

  1. The read tool calls lsp.touchFile(filepath, false) via the warm function (src/tool/read.ts:81-84)
  2. This spawns LSP clients asynchronously using Effect.forkIn(scope) - fire-and-forget
  3. When a new LSP client is created, Bus.publish(Event.Updated, {}) is called (src/lsp/lsp.ts:314)
  4. This should trigger the TUI to refresh LSP status via the lsp.updated event

The problem: The LSP activation happens asynchronously, and there's a race condition where:

  • The sidebar checks sync.data.lsp which is empty initially
  • The LSP client is still being spawned in the background
  • The event is published but the sidebar may not update correctly
  • The message "LSPs will activate as files are read" persists even after activation

Additional Context

Looking at the code flow:

  • read.ts line 164: yield* warm(filepath) triggers LSP activation
  • lsp/lsp.ts line 314: Bus.publish(Event.Updated, {}) fires when client is added
  • sync.tsx line 310-313: Listens for lsp.updated and refreshes status
  • lsp.tsx line 36: Shows "LSPs will activate as files are read" when list().length === 0

The issue appears to be that the LSP status isn't being properly synchronized to the TUI state even after the event is published. This could be a timing issue or a problem with how the event is being handled in the plugin context.

Possible Solutions

  1. Ensure the LSP status is refreshed immediately after touchFile completes, not just via the event bus
  2. Add a polling mechanism or force refresh when the sidebar is rendered
  3. Make the LSP activation synchronous for the first file read to ensure proper state initialization
  4. Add debugging/logging to trace the event flow from Bus.publish to the TUI update

oh-my-opencode.json

// Default configuration, LSP enabled

OpenCode version

Latest upstream (anomalyco/opencode)

oh-my-opencode-slim version

Latest main branch

Operating system

macOS / Linux / Windows (all affected)

Logs, screenshots, or extra context

The issue is reproducible with the built-in opencode LSP integration when using orchestrator agents that read files programmatically. The LSP tool works correctly when called directly, but the automatic activation via file reads doesn't update the UI state properly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions