[sasa-tomic]

Hi! Thanks for the GREAT plugin. Absolutely brilliant, and pretty much the only reason I use opencode and not something else!

Now, the upgrade of opencode to v2 caused some problems. In particular, when opencode backend service restarts, the compression seems to break.

I asked the AI to fix that, plus a few other papercuts.

Please take a look and pick whatever makes sense to you.

[TomLucidor]

Does this include the other one? #628

[amnesiaof]

I'd hold off on merging. Four things are actually broken, and two of them reintroduce the class of bug this PR sets out to eliminate.

The worst is lib/state/persistence.ts:83. The atomic write is writeFile(tmp) followed by rename(tmp, file), and on Windows two renames onto the same existing target collide. I hit EPERM 169 times out of 400 concurrent renames, same result on five consecutive runs. It fires from normal use: lib/state/state.ts:56 calls saveSessionState without awaiting it, then line 64 awaits refreshManualMode, which writes the same file again. The catch at persistence.ts:130 logs one error and moves on, so the state is gone. Both failing tests in this branch are this, and both pass on master.

Serializing writes per state file covers the DCP-against-DCP case. You also want a bounded retry on EACCES/EPERM/EBUSY, because a mutex cannot beat an A/V scanner holding the directory. npm ships that shape in graceful-fs if you want the reference.

Three smaller ones, a few lines each. subagent-results.ts:73 still tests part.tool === "compress", a leftover the rename missed, which silently stops buildSubagentResultText from merging pre-compress assistant text. prompts/index.ts:15 only replaces the exact phrase "compress tool", so the main system prompt still tells the model the tool is called compress while the registered tool is dcp_compress. And compress.toolName never reaches isCompressToolPart in messages/query.ts, so any custom name goes undetected.

Two things I checked and one I got wrong. The theme bridge in lib/v2/theme.ts and the feature detection in lib/v2/tui.tsx are the strongest parts of this PR, and surfacing persist failures as visible warnings is what made the state bug visible in the first place. Using ctx.permission.hook("evaluate", …) for compress permission is correct: the v2 docs say an explicit configured deny is final and does not invoke the hook, so it cannot override a user's own deny.

An earlier draft of this comment flagged that same hook for overriding an explicit deny, and raised a question about whether ctx.permission.hook was documented at all. Both claims were wrong and both findings are gone.

Everything below is in code this PR introduced or modified, so I would fix it here rather than in follow-ups. I also read the diff for added complexity and found nothing worth acting on. There are two cosmetic shrinks in theme.ts (eleven firstDefined calls where eight are the same .base/.default suffix swap, and selectedListItemText recomputing what background already has, worth about 37 lines) which I am deliberately leaving out rather than adding noise to a diff this size.

Full audit, 9 findings with line references

Verification: tsc --noEmit clean. bun test on this branch gives 163 pass and 3 fail, one of which is only a missing build artifact. The two real failures, persistence-regression.test.ts and v2-ids.test.ts, give 6 pass and 0 fail on master, so both are PR-introduced. New API usage was checked against the installed @opencode/plugin@2.0.16 and @opencode/ai typings and against the published v2 plugin docs. Windows rename behaviour and Zod 4 were checked against upstream docs.

The four blockers

lib/state/persistence.ts:83-84 — covered above. Two extra notes: the temp-path uniqueness change (pid + sequence + 4 random bytes) is a correct fix for the interleaved-write bug it describes, it just does not cover this second failure mode. And a failed rename orphans the .tmp file permanently.

lib/subagents/subagent-results.ts:73

part.type === "tool" && part.tool === "compress" && part.state?.status === "completed",

A duplicate of messageHasCompress, which this PR did fix. Delete it and use isCompressToolPart from lib/messages/query.ts.

lib/prompts/index.ts:15

text.replaceAll("compress tool", `${toolName} tool`)

Only matches that exact phrase, but lib/prompts/system.ts:9,14,35 writes escaped backticks around compress, which this never touches. Use a {{compressTool}} placeholder so a missed site becomes a compile error rather than a silent mismatch.

lib/messages/query.ts:36-38

part.tool === LEGACY_COMPRESS_TOOL_NAME || part.tool === DEFAULT_COMPRESS_TOOL_NAME

compress.toolName is validated at config.ts:553 and documented in the README, but detection only ever compares the two constants. Set it to a custom value and messageHasCompress, the v1 event hook at lib/hooks.ts:318 and the recompress paths all go blind. Pass the resolved name in, or share the helper the registration path uses.

The five medium ones

lib/v2/index.ts:228-239 and :74 — compressDefinitionFor() builds against a throwaway createSessionState() (no session, idFormat is "xml", empty messageIds), then memoizes it for the process lifetime. Latent today only because state.idFormat is never assigned anywhere in lib/, which is also true on master, but it becomes a live format-mismatch bug once compact-id support lands. Separately, the catch at :74 returns { type: "object", properties: {} }, so a throw from z.toJSONSchema silently exposes a zero-arg compress tool. Falling back to the zod schema does not help, the field is consumed as JSON Schema. Zod 4 defaults to unreferable: "throw", so pass { unrepresentable: "any" } and keep the real schema.

lib/messages/sync.ts — removing the !hasOriginMessage → deactivate branch means blocks whose origin has left the rolling window are never deactivated. Since this PR's own buildCompressedBlockGuidance lists every active block with its token cost, those phantoms permanently burn prompt tokens and get advertised as DROP or MERGE targets for ranges that no longer exist. Filter in the guidance builder, or reintroduce a persisted "origin is gone" tombstone.

lib/state/utils.ts:48 and sync.ts:49-50, :127 — activeByAnchorMessageId is persisted and cleared plus rebuilt on every sync, but syncCompressionBlocks returns true only when deactivatedCount > 0 || reactivatedCount > 0. Anchor-map-only changes never trigger a persist.

lib/token-utils.ts:39-41 — this guard is unreachable:

if (foundTokens) {
  return 0
}

foundTokens is set at :21 and both branches return immediately at :28 and :36, so the loop can never fall through with it true. The intended guard, don't estimate when a compaction reset is known, does not exist. The consequence is worse than dead code: when no assistant message carries tokens, the fallback sums all messages including pre-compaction ones, giving a large over-estimate right after a compaction and spurious maxContextLimit nudges. The comment's reasoning also reads inverted, since triggering a nudge needs the estimate high enough to cross the threshold.

lib/prompts/extensions/nudge.ts — two issues in the same new code. estimateMessageTokens applies its own unconditional chars/4, so the codebase now carries two token estimates that can disagree widely; the chars/4 fallback inside countTokens is pre-existing, the second path is what is new. And it charges part.url.length for file parts, where per the comment in the code v2 carries projected media as base64 in url. An attached image is therefore counted by its base64 payload, roughly four thirds of the bytes divided by four again, instead of its media cost. That is off by orders of magnitude and would advertise exactly that message as the top drop candidate. Clamp to the provider's media cost or skip file parts.

lib/messages/inject/utils.ts:336 — buildMessageOccupancyGuidance is built eagerly, so estimateMessageTokens runs JSON.stringify(part.state ?? {}) for every tool part in the session even when applyRangeModeAnchoredNudge early-returns because no anchor fired. Needs a thunk, or an anchorMessageIds.size > 0 gate.

Nit

lib/config.ts:700 — the pruneNotificationType default flipped from "chat" to "toast" globally, but the rationale (v2 hosts do not strip ignored parts) is v2-specific. v1 uses client.tui.showToast at lib/ui/notification.ts:119-133, which works, so existing v1 users silently lose in-chat persisted notifications.

Checked, no findings

lib/v2/messages.ts links every projected part at :184, so the edit.ignored skip in restore() is correct and the added unlinked path cannot leak DCP chat text. prune.tools is only ever .set(), so the size check at :300-311 is a valid proxy for pruneToolsChanged. The Media.Asset migration with part.media.inline() and part.media.mediaType matches the @opencode/ai 2.x schema.

[TomLucidor]

@amnesiaof will you make a separate PR then?