Is the destruction of the TreeSitter client causing a memory leak? #36454

Activity

1. github-actions

   assigned

   kommander

   on Jul 11, 2026
2. c17r commented on Jul 16, 2026

   

   c17r

   on Jul 16, 2026

   More actions

   I'm also seeing this in 1.18.2 on MacOS
3. AndyLuoJJ commented on Jul 23, 2026

   

   AndyLuoJJ

   on Jul 23, 2026

   More actions

   Still exists in 1.18.4 on macOS

   
4. zengyuxiang0921 commented on Jul 30, 2026

   

   zengyuxiang0921

   on Jul 30, 2026

   More actions

   Same bug on windows node.js
5. zengyuxiang0921 commented on Jul 30, 2026

   

   zengyuxiang0921

   on Jul 30, 2026

   More actions

   Try removing mcp servers that can't load, that works for me
6. jizhi0v0 commented on Aug 14, 2026

   

   jizhi0v0

   on Aug 14, 2026

   More actions

   This isn't a memory leak — it's a shutdown race in @opentui/core, and there's already a fix sitting upstream that nobody here seems to know about:

   • Code highlighting failed, falling back to plain text warning logged on exit (destroy race) opentui#1319 — the issue
   • fix(core): don't warn when tree-sitter highlight fails during client destroy opentui#1318 — the fix (open, unreviewed)

   What's actually happening

   TreeSitterClient.destroy() rejects every in-flight highlightOnce() request in one shot via rejectPendingRequests(), which walks the whole messageCallbacks map. CodeRenderable.startHighlight() catches each rejection and logs it as a genuine highlighting failure — the console.warn at Code.ts:418 runs before the if (this.isDestroyed) return on the next line.

   So the count of warnings tracks the number of queued highlight requests, not anything leaking. That's why it looks worse the longer the session has been running: more rendered code blocks in the transcript, more pending requests to reject.

   Still reproducing on 1.18.18

   macOS arm64. The v1.18.18 tag pins @opentui/core 0.4.5, and the shipped bundle still has the warn ahead of the guard:

   $ strings -a ~/.opencode/bin/opencode | grep -o 'Code highlighting failed.\{0,120\}'
   Code highlighting failed, falling back to plain text:",H),this.isDestroyed)return;this.textBuffer.setText($)...
   

   Two things that may help people triaging this

   It never reaches the log file. On my machine:

   $ grep -c "TreeSitter client destroyed" ~/.local/share/opencode/log/opencode.log
   0
   

   The warnings go straight to the terminal because finalizeDestroy() calls _console.destroy() → restoreOriginalConsole() in the same synchronous block, while the rejections settle on a later microtask — by the time they fire, global.console is the original one again. So if you're looking for these in opencode.log, they aren't there.

   The warning path itself is renderable-side only (console.warn + textBuffer.setText), so it can't touch persistence. On the session I hit this with, all 209 messages were intact in opencode.db and opencode -s <session-id> resumed fine — the only casualty was the assistant turn that was mid-stream when Ctrl+C landed (cost: 0, all token counts 0), which just needs re-sending.

   FWIW, the "remove MCP servers that can't load" workaround mentioned above addresses a different failure — it doesn't affect this particular stack.
7. ljsga commented on Sep 6, 2026

   

   ljsga

   on Sep 6, 2026

   More actions

   This is still happening on 1.18.29 runnin gon macos 26.6.2
8. serezha93 commented on Sep 11, 2026

   

   serezha93

   on Sep 11, 2026

   Last edited by serezha93

   More actions

   Reproduces for me on macOS with OpenCode 1.18.30. On a normal TUI shutdown the terminal prints:

   Code highlighting failed, falling back to plain text: warn: TreeSitter client destroyed
   

   This looks like the same shutdown race tracked upstream in anomalyco/opentui#1319, which was closed as completed after renderer teardown was changed to invalidate pending CodeRenderable highlights before Tree-sitter shutdown.

   OpenCode dev still pins @opentui/core, @opentui/keymap, and @opentui/solid to 0.4.5. There is also an existing, separately-motivated OpenCode upgrade PR, #46112, that moves the renderer stack to a newer OpenTUI for another rendering issue.

   @kommander could you check whether #36454 disappears with the newer OpenTUI teardown and, if so, fold this into the dependency upgrade? If it does not, a teardown regression test would at least make the remaining gap explicit.

   I'm not claiming the bump fixes it without verification — just cross-linking the upstream fix/status and the existing upgrade path.
9. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
10. thdxr

    closed this as not plannedon Oct 11, 2026