opencode plugins: V2 primary-session prompt hangs when @cortexkit/opencode-magic-context@0.42.6 is loaded

[deltacat]

Short description

opencode v2 hangs when the plugin enabled

What happened?

Summary

Loading the third-party plugin @cortexkit/opencode-magic-context@0.42.6 as a server plugin
(plugins in opencode.jsonc) makes OpenCode V2 primary-session prompts hang: the user message
is accepted but no assistant response ever arrives. Removing the plugin restores normal responses
immediately.

Environment

• opencode version: 2.0.11
• OS: Linux 6.6.87.2-microsoft-standard-WSL2 (WSL2), x86_64
• Terminal: TERM=xterm-256color, TERM_PROGRAM=vscode, COLORTERM=truecolor
• Shell: /bin/zsh
• Install/channel: latest
• Active plugins: none while reproducing the workaround; plugin under test is
  @cortexkit/opencode-magic-context@0.42.6 (latest on npm, published 2026-09-19), which declares
  OpenCode 2 support.

Reproduction

1. Add @cortexkit/opencode-magic-context@latest to plugins in ~/.config/opencode/opencode.jsonc
   (server config) and set compaction.auto: false.
2. Start or restart OpenCode V2. (Config hot-reload also picks the change up.)
3. Open a session and submit any prompt.
4. The prompt is accepted, but no assistant response is produced; the session appears to wait forever.

Expected Behavior

The plugin loads, the session responds normally, and Magic Context manages context.

Actual Behavior

The session never responds. Observed diagnostics:

• Server log shows the plugin loaded repeatedly within a single run (6 loads in one run; e.g. 4 loads
  within one second at 2026-09-21T01:17:56).
• During the hung window the plugin wrote nothing to its data dir
  ~/.local/share/cortexkit/magic-context/ (rpc/ and context.db kept an older timestamp),
  suggesting it stalls before initializing storage.
• No FailClosedBlockingError was logged during the V2 period.
• Removing the plugin from plugins immediately restores responses.

Additional Context

• The plugin is V2-aware: 0.42.6 ships dist/v2/server.js, detects a V2 host via ctx.session.hook,
  and writes model-context-limits-opencode2.json.
• It declares "oc-plugin": ["server", "tui"] and exports . (server) plus ./tui (terminal).
• Its config exposes fail_closed_blocking (default true): "When Magic Context cannot operate
  (schema fence mismatch, storage open/migration failure), block the primary-session prompt with a
  loud recovery error". No such error appeared in the logs, so the hang looks more like an early
  setup deadlock than the fail-closed path.
• Registration placement verified: cli.json plugins only loads terminal-only plugins, so the
  server half must live in opencode.jsonc plugins. Both "server only" and "server + cli"
  placements still hang.
• Workaround in use: keep the plugin disabled. Reproducibility: consistent (100%).

Diagnostics

Plugin version

0.42.6

OpenCode version

2.0.11

Platform

Win11 x64 -> WSL2

Client

OpenCode TUI (CLI)

Log output (optional)

[deltacat]

Follow-up: root cause identified (Maybe)

We traced the unresponsive-session hang to the V2 store generation detection.

Root cause

OpenCode V2 migrated the SQLite store in place but kept the legacy V1 tables, so the database carries both generations at once:

• message (V1) — 14765 rows, last write 2026-09-15
• part (V1) — 54082 rows, last write 2026-09-15
• session_message (V2) — live, written up to now

detectOpenCodeStoreGeneration() checks the V1 tables first:

const hasV1Messages = tables.has("message") && tables.has("part");
if (hasV1Messages) return "v1";              // matches → returns "v1"
if (tables.has("session_message")) return "v2";

So a V2 store that still carries message + part is classified as v1. V2StoreReader then asserts expected v2 and throws:

OpenCode store generation mismatch at ~/.local/share/opencode/opencode.db:
expected v2, found v1; refusing generation-specific database access

That throw is swallowed by refuseIfUnsafe() on the context session hook, which sets unsafe = true and calls interruptBeforeProvider() → session.interrupt() before the provider runs. Result: every prompt is interrupted and the session never produces a response.

Note: fail_closed_blocking: false does not change this — the interrupt comes from refuseIfUnsafe, not the fail-closed path.

Evidence

• Store contains both generations: message=1, part=1, session_message=1.
• V1 history was copied into V2: 14758/14765 message ids also exist in session_message; 257/257 session ids exist in session_v2; session_message holds history back to 2026-04-23 (same origin as V1).
• session_v2 is a superset of session (adds fork_session_id, fork_boundary, time_suspended, resume_attempts, time_idle, idle_outcome), consistent with a "create new tables, copy data" migration.
• After migration only session_message is written; message/part stopped at 2026-09-15.
• The legacy tables are still referenced by other tables (todo, session_share, instruction_entry, instruction_state), so dropping them is not a safe fix.
• With detection forced to v2, the reader's queries run fine against the live session_message (indexed on (session_id, seq)).

Suggested fix

function detectOpenCodeStoreGeneration(db, schema = "main") {
  const tables = schemaTableNames(db, schema);
  if (tables.has("session_message")) return "v2";   // check V2 first
  const hasV1Messages = tables.has("message") && tables.has("part");
  if (hasV1Messages) return "v1";
  if (tables.has("session") || tables.has("project")) return "v1";
  return "unknown";
}

Alternatively, make assertOpenCodeStoreGeneration treat "both present, session_message exists" as v2, or make the V2 reader tolerant of extra legacy tables.

Environment

• opencode 2.0.11, @cortexkit/opencode-magic-context 0.42.6
• Linux (WSL2)
• DB: ~/.local/share/opencode/opencode.db (~1.19 GB)
• Reproducible: 100% while the plugin is enabled

[magic-alfonso]

Thanks for the detailed report — the diagnostics you collected were what made this tractable.

I rebuilt your setup against the released 0.42.6 package and a real OpenCode 2.0.11 host, and I
could not get it to hang: eleven runs (plugin registered by path, by pinned version and by
@latest; in the global config and in a project config; one open directory and six; one prompt
and six) all answered normally. So there doesn't appear to be a deadlock in the plugin itself,
and I want to be upfront that I haven't reproduced your exact failure.

What I did reproduce is a long wait with exactly your symptoms, and I think it's the most
likely explanation:

OpenCode 2.0.11 doesn't load a server plugin when it starts. It loads it when you send your
first message. If the plugin isn't already in OpenCode's plugin cache, OpenCode downloads and
installs the whole package right then — inside your prompt, with no progress shown. Until that
finishes, your message sits there accepted with no reply, and nothing is written to the plugin's
data directory, because the plugin hasn't started yet. That matches all three of your
observations.

On my machine that install took about 12–15 seconds. The package is large (4 MB download, 22 MB
and 1122 files on disk), and writing a thousand small files is the slowest thing WSL2 does —
especially if the path is on the Windows side. Minutes there would not surprise me.

Two things would tell us whether that's your problem:

1. Send a prompt and give it several minutes rather than a few. If a reply eventually
   arrives, this is the install, and it's a one-time cost — the next start is fast.
2. Check where the cache lives. If XDG_CACHE_HOME or your home directory is under /mnt/c,
   moving them to the Linux filesystem will make a large difference.

Also worth pinning the version — @cortexkit/opencode-magic-context@0.42.6 instead of @latest
— so OpenCode isn't re-resolving latest against npm.

Two of your diagnostics are explained and aren't signs of trouble:

• The missing rpc/ directory is expected: 0.42.6 doesn't have that component at all. It was
  added after the release, so its absence tells us nothing either way.
• The plugin loading 6 times is normal. OpenCode 2.0.11 loads a plugin once per open
  directory, so six loads means six directories were active, and four appearing in the same
  second is just several opening together at startup. I ran six directories in one process and
  they all worked, so the repeated loads aren't interfering with each other.

If it still hangs after a long wait, could you send:

• the size of ~/.local/share/cortexkit/magic-context/context.db, and whether you used an
  earlier version of the plugin before this (a large database being upgraded is the one path I
  couldn't rule out);
• whether any other OpenCode or Magic Context process is running at the same time;
• ls -la ~/.cache/opencode/npm/ (or $XDG_CACHE_HOME/opencode/npm/) during the hang, so we can
  see whether the install is still in progress.

Separately, thanks — this did surface a real bug in 0.42.6, unrelated to the hang: the plugin
re-registered a tool-description change on every request, which slowly accumulated in the host
and could leak one session's shortened tool descriptions into later requests. That's fixed and
will go out in the next release.

[deltacat]

Thanks for you detail answer. Here are some more investigation according your guidline:

At first, $XDG_CACHE_HOME is empty, it means we are using default path ~/.cache, and magic context is there:

(py313) ➜  @cortexkit pwd
<home>/.cache/opencode/npm/@cortexkit
(py313) ➜  @cortexkit du -h -d 1
1.2G    ./opencode-magic-context@0.42.6
606M    ./opencode-magic-context@latest
1.8G    .

And I test again, enable magic context, use fixed versio (0.42.6) instead of @latest:

opencode.jsonc:

{
  "$schema": "https://opencode.ai/config.json",
  "plugins": [
    "@cortexkit/opencode-magic-context@0.42.6",
  ],
  "model": "opencode-go/deepseek-v4.1-flash",
}

tui.jsonc:

{
  "plugin": [
    "@cortexkit/opencode-magic-context@0.42.6"
  ]
}

Then send some message, after 10+ minutes, nothing happend.

Magic context sidebar show "loading" at first, several seconds later, it became this:

[magic-alfonso]

Thanks — that rules out the install: pinned, already cached, and still nothing after 10 minutes. The sidebar getting past "loading" also tells me the TUI half is up, so the server half is stuck somewhere after it is loaded and before it answers the first context pass.

The most likely place left is the database open. On OpenCode 2 the plugin is loaded inside your first prompt, and the first thing it does is open ~/.local/share/cortexkit/magic-context/context.db and apply any pending schema migrations synchronously. If that database was created by an earlier plugin version (you have both @latest and 0.42.6 cached, so I suspect an older version ran at some point), several of the migrations between versions rewrite large tables — on WSL2 that can take a long time, and while it runs the main .db file keeps its old timestamp because SQLite writes to the -wal file first. That would match everything you saw.

Could you send, during a hang:

1. ls -la ~/.local/share/cortexkit/magic-context/ — the sizes of context.db, context.db-wal and context.db-shm, and whether the -wal file is growing.
2. The plugin log: ~/.local/share/cortexkit/magic-context/logs/magic-context.log (or, on older layouts, /tmp/opencode/magic-context/magic-context.log) — the last 100 lines are enough.
3. Whether this machine ran an earlier plugin version before 0.42.6.
4. What the sidebar says once it stops loading (the image did not come through for me; the text is enough).

If the -wal is growing, that is the migration and it will finish; I will still make it non-blocking and visible, because ten silent minutes inside a prompt is not acceptable regardless of the cause.

[deltacat]

question 1: seems the wal file (and other db file) keeps unchanged:

(py313) ➜  magic-context date && ls -al
Mon Sep 21 22:11:53 CST 2026
total 85448
drwx------  4 leon leon     4096 Sep 21 09:47 .
drwxr-xr-x  4 leon leon     4096 Aug  6 15:57 ..
-rw-------  1 leon leon 87420928 Sep 21 08:19 context.db
-rw-------  1 leon leon    32768 Sep 21 19:37 context.db-shm
-rw-------  1 leon leon        0 Sep 21 12:06 context.db-wal
-rw-r--r--  1 leon leon       31 Sep 17 13:21 last-update-check.json
-rw-r--r--  1 leon leon        6 Jul 10 08:16 last_announced_version
-rw-------  1 leon leon     6754 Sep 17 13:21 model-context-limits-opencode.json
-rw-------  1 leon leon     6754 Sep 17 11:42 model-context-limits-opencode2.json
drwx------  3 leon leon     4096 Sep 17 11:47 models
drwxr-xr-x 17 leon leon     4096 Sep 17 11:31 rpc
(py313) ➜  magic-context date && ls -al
Mon Sep 21 22:12:11 CST 2026
total 85448
drwx------  4 leon leon     4096 Sep 21 09:47 .
drwxr-xr-x  4 leon leon     4096 Aug  6 15:57 ..
-rw-------  1 leon leon 87420928 Sep 21 08:19 context.db
-rw-------  1 leon leon    32768 Sep 21 19:37 context.db-shm
-rw-------  1 leon leon        0 Sep 21 12:06 context.db-wal
-rw-r--r--  1 leon leon       31 Sep 17 13:21 last-update-check.json
-rw-r--r--  1 leon leon        6 Jul 10 08:16 last_announced_version
-rw-------  1 leon leon     6754 Sep 17 13:21 model-context-limits-opencode.json
-rw-------  1 leon leon     6754 Sep 17 11:42 model-context-limits-opencode2.json
drwx------  3 leon leon     4096 Sep 17 11:47 models
drwxr-xr-x 17 leon leon     4096 Sep 17 11:31 rpc

question 2:
strange, I can't see logs under the both path.

question 3:
yes, I'd ran older version then upgrade to latest. But now, there is only one version (0.42.6)

question 4:
sidebar loading...then changed display. No any other message.

Context
17,438 tokens
2% used
$0.11 spent
Magic Context · loading…

->

Context
17,438 tokens
2% used
$0.11 spent
Magic Context
Context 0 tokens
Historian idle · C:0
Memories 0/0 · Q:0

[magic-alfonso]

That rules out a migration: the WAL is empty and context.db has not been written since 08:19, so nothing is being rewritten. The -shm timestamp (19:37) shows the plugin did open the database, and the sidebar's second state (Context 0 tokens · Historian idle · C:0 · Memories 0/0) means the plugin's server half answered the sidebar — with an empty session. So the plugin loads, opens storage, and then the prompt never reaches it (or reaches it and stalls inside our context hook).

The log path I gave you was the OpenCode 1 one — my mistake. On OpenCode 2 the plugin writes under its own harness name:

/tmp/opencode2/magic-context/magic-context.log

(or $TMPDIR/opencode2/magic-context/magic-context.log if TMPDIR is set). The last ~100 lines during a hang are what I need; if that file does not exist either, please say so — that alone tells me the server half never got as far as its first log line.

Two more quick ones, both from the same directory listing: the rpc/ folder has 17 entries from Sep 17 — ls -la ~/.local/share/cortexkit/magic-context/rpc/ — and ls ~/.local/share/opencode/ (whether the store is opencode.db, opencode-local.db, or opencode2.db). I'm reproducing on my side with a database that carries earlier OpenCode 1 sessions and is then opened by 2.0.11, since that is the shape yours has.

[magic-alfonso]

Found it, and it is a bug in the released 0.42.6 — thank you for the listings, the rpc/ folder from Sep 17 was the clue.

Mechanism. OpenCode 2 migrates an existing OpenCode 1 opencode.db in place and keeps the old message/part tables next to the new session_message. The store-generation detector in 0.42.6 sees those v1 tables and classifies the store as OpenCode 1, so the OpenCode 2 reader refuses on every prompt. The refusal path interrupts the turn before any provider request: the host records the user message and an idle outcome=interrupted row, no assistant row, nothing on screen — exactly what you see. The "Magic Context · loading… → Context 0 tokens" sidebar is the plugin's server half answering with an empty session, which fits. Reproduced 4/4 on a real 2.0.11 host with the published 0.42.6 bytes on a data root that had earlier OpenCode 1 sessions; a fresh root answers, which is why my first round did not catch it.

Why no log: that refusal was written only to OpenCode's console log, never to magic-context.log. Fixed on master today so the next report of this shape carries its cause.

The fix is already on master (16da14ce, 6 hours after the 0.42.6 tag — a migrated store now passes the OpenCode 2 assertion), verified against the same reproduction. It ships in v0.42.7, which I am cutting shortly; I will post here when it is on npm.

Until then, two honest options. Rolling back to 0.42.5 is not a workaround — 0.42.5 does not answer on 2.0.11 at all (same silent shape, different cause). What does work is pointing OpenCode 2 at its own store file:

OPENCODE_DB=opencode2.db opencode

Verified to answer normally (first prompt 598 ms). The tradeoff is real: OpenCode 2 starts on an empty session store, so your OpenCode 1 sessions are not visible in it until you drop the variable after the release.

One thing I could not match: your context.db-wal at 0 bytes. In my reproduction a refused turn still writes a session-meta row before the reader refuses, so the WAL grows. Not needed to fix this, but if the refusal in your case happens even earlier I would like to know — the log line above will now say.

[deltacat]

Great! Very glad to see the progress. Also, I tried to reproduce it and captured the log as follows.

[2026-09-23T00:25:23.724Z] [magic-context] SQLite boot busy timeout: backend=Bun timeout=5000ms path=~/.local/share/cortexkit/magic-context/context.db
[2026-09-23T00:25:23.780Z] [magic-context] upstream migration lane at boot: database=v85, supported_fence=v85

[magic-alfonso]

Thanks, that log fits. database=v85, supported_fence=v85 is 0.42.6 booting cleanly; the refusal comes later, on the first prompt, and 0.42.6 only reported it to OpenCode's console. The version with the fix writes it to magic-context.log as well.

A correction on timing: I said I'd cut the fix "shortly" two days ago and haven't. While testing OpenCode 2 end to end on a copy of a large real store, we found and fixed several more OpenCode 2 problems that a converted store triggers (compaction markers dropped by the converter, whole-session reads on every pass, the first-prompt refusal you hit, the historian not running). Rather than ship a partial fix, they're going out together in the next release. I'll post here when it's on npm.

Until then, OPENCODE_DB=opencode2.db opencode remains the working option, with the tradeoff I described above.

[MCKLtech]

Another data point for this issue. The root cause is the same as #477 / #486: the store check reads a 1.18 → 2.x migrated store as v1. The fix is merged, but npm latest is still 0.42.6, so OpenCode 2 users still get this. Can you publish a release with the fix?

Environment

• macOS 14 (Darwin 23.6.0), Apple Silicon
• OpenCode 2.0.15, bundled with OpenChamber desktop 2.0.0 (/Applications/OpenChamber.app/Contents/Resources/opencode-cli/opencode)
• OpenCode 1.18.32 CLI on the same machine
• Both hosts use the same store: ~/.local/share/opencode/opencode.db (4.8 GB, migrated in place from 1.18)
• @cortexkit/opencode-magic-context 0.42.6 on OpenCode 2
• Magic Context DB (~/.local/share/cortexkit/magic-context/context.db): schema_migrations at v85
• Other plugin: oh-my-opencode-slim 2.2.24

Symptom

In OpenChamber, every prompt ends with:

OpenCode interrupted this reply.
OpenCode reported no details.

OpenCode sends no request to the provider. opencode.log and the OpenChamber log have no error line. A session export shows the user message, then this about 60 ms later:

{"type":"idle","outcome":"interrupted"}

Reproduction

1. Use a store that OpenCode migrated from 1.18 to 2.x. It has message, part and session_message:

   $ sqlite3 -readonly opencode.db "SELECT name FROM sqlite_master WHERE type='table' AND name IN ('message','part','session','project','session_message');"
   project
   message
   part
   session
   session_message
   

   message has 63,099 rows and session_message has 63,093 rows.

2. Use a config with only this plugin and no MCP servers: "plugin": ["@cortexkit/opencode-magic-context@latest"].

3. Run:

   opencode run --standalone --print-logs -m deepseek/deepseek-flash "Reply with the single word OK."
   

Result: no reply. The warning below shows only on stderr with --print-logs:

[magic-context] v2 refuseIfUnsafe warn: OpenCode store generation mismatch at ~/.local/share/opencode/opencode.db: expected v2, found v1; refusing generation-specific database access
      at assertOpenCodeStoreGeneration (.../dist/index-a9ssj59b.js:134:13)
      at new V2StoreReader (.../dist/index.js:45173:7)

With no plugins, the same command replies OK. With only oh-my-opencode-slim, it also replies OK.

Findings

• detectOpenCodeStoreGeneration() returns v1 because message and part exist, and it does not check session_message first. This is the bug that fix(opencode2): accept v1 stores migrated to OpenCode 2 #477 and fix(store): detect 1.18→2.x migrated stores as v2 #486 fix.
• "fail_closed_blocking": false in the user-level magic-context.jsonc does not help. The V2StoreReader refusal still interrupts the prompt, so no config setting works around it.
• The refusal goes only to the host console. It is not in opencode.log or in the OpenChamber app log, so users see "no details". (You said in this thread that the fixed version also writes it to magic-context.log.)

Related: 1.18 and 2.x hosts that share one store

OpenCode 2 loaded 0.42.6, which migrated context.db to v85. The 1.18.32 CLI still had 0.42.5 in ~/.cache/opencode/packages/@cortexkit/opencode-magic-context@latest/, because the @latest plugin spec did not refresh that cache. After the migration, every 1.18 prompt failed:

FailClosedBlockingError: Magic Context cannot operate: this Magic Context build is older than the database; upgrade/restart this harness (upstream migration lane v85, build supports through v84). Recovery: npx @cortexkit/magic-context@latest doctor

When I deleted that cache folder, 1.18 downloaded 0.42.6. Users who run 1.18 and 2.x at the same time can get this. It may need a doctor check or a note in the docs.

Small doctor issues

• npx @cortexkit/magic-context@latest doctor --help starts the doctor. It does not print help.
• The doctor lists only the PATH install (1.18.32) and /Applications/OpenCode.app ("unknown" version). It does not find the OpenCode 2.0.15 binary bundled in OpenChamber, which is the host that failed.
• The CLI requires Node >= 24 (EBADENGINE warning on Node 22.22.3).

Workaround in use

I removed the plugin from opencode.json and tui.json, and set compaction.auto: true. I will add the plugin back after a release newer than 0.42.6.

[magic-alfonso]

Thanks, this is a very clear write-up. You're right on every point. The store-generation fix and the log line are on master and ship in 0.43.0, which is in its final checks now. Until then, OPENCODE_DB=opencode2.db (from my earlier comment) is the only workaround, and fail_closed_blocking doesn't affect this refusal.

The shared-store case is a good catch. When OpenCode 1.18 and 2.x use the same context.db and load different plugin versions, the newer one migrates the database and the older one then refuses every prompt. @latest in the plugin spec doesn't refresh a cached copy, so it's easy to end up there. We'll make doctor compare the cached plugin version for each host against the database's schema and say which cache to clear. We'll also document it for people running both.

We'll fix the three doctor issues too: --help should print help, the OpenCode binary bundled inside OpenChamber should be discovered, and the Node version requirement needs a look.

[ualtinok]

Shipped in 0.43.0. A store that OpenCode 2 converted from OpenCode 1 is now recognised as OpenCode 2, so the first prompt answers, and any refusal is also written to magic-context.log instead of only to OpenCode's console. The OPENCODE_DB=opencode2.db workaround is no longer needed. @MCKLtech, the doctor follow-ups you raised (a shared database between 1.18 and 2.x with different cached plugins, --help, the OpenChamber binary, and the Node requirement) are tracked and will come in a later release. Closing this one.