ctx_reduce availability ignores OpenCode agent/session permissions, so a session that can't call ctx_reduce still gets §N§ prefixes and ctx_reduce nudges

[iceteaSA]

Refs are against master da0cf178a; the resolver is unchanged from v0.42.6.

The gate

The §N§ prefix, Channel 1, Channel 2, and the reduce guidance all gate on one verdict, resolveToolAvailabilityFromMessages (ctx-reduce-availability.ts:130-159). It is derived only from the tools map on the session's first user message (verdictFromToolsMap(message.info.tools, toolName) ?? true, :150), fails open to callable, and is then frozen.

The file says the live permission rules are deliberately excluded:

The ctx_reduce verdict intentionally remains frozen even when OpenCode's live permission rules deny the tool. (:23-28)

The live read (resolveToolPermissionDenied, :336) only feeds a log on cache-busting passes: "ctx_reduce permission is denied by OpenCode; frozen guidance remains until session restart" (transform-postprocess-phase.ts:1416-1434).

Why that leaves the deny path uncovered

The freeze rationale is sound: a verdict that flips mid-session would bust the prefix. But the design assumes a permission deny shows up in the first-message tools map. On OpenCode it doesn't. Measured on a live host over the last 14 days: 894 subagent sessions, 0 with a non-empty first-user-message tools map. That includes agents whose permissions deny edit/write (explore, reviewer, verifier, gate-runner), and none of their first messages carry edit: false. Agent and session permissions live on the agent config and session.permission, which is exactly what resolveToolPermissionDenied reads. They are not written into message.info.tools.

So for a session whose agent denies ctx_reduce:

• OpenCode removes the tool, and the model cannot call it.
• MC resolves callable: true (empty map means no signal, which fails open), freezes it, and keeps adding §N§ prefixes, the reduce guidance, and Channel 1/2 "make a ctx_reduce pass" nudges. That is the cargo-cult case the resolver's header says it exists to prevent.
• The log's "until session restart" doesn't hold for this case. A restart, or a fresh session, re-derives from the same empty map and lands on callable: true again.

The first-message map only covers an explicit per-prompt tools map, and OpenCode's task tool isn't sending one here (0/894).

Suggested shape

Fold the permission read into the one-time freeze instead of keeping it log-only. The agent and session permissions are fixed at spawn, so evaluating them once when the verdict freezes keeps the no-flap property. resolveToolPermissionDenied is async while the freeze path is sync, so the read likely has to happen at session.created (or on the first pass), with the freeze waiting for it the same way the provisional frozen: false verdict already defers system-prompt-hash persistence. A mid-session permission change would stay log-only as it is today.

Verification status

• Resolver and log path: read at source on master da0cf178a
• 894/894 empty first-message tools maps: measured in opencode.db on one host (OpenCode 1.x)
• That a denied session receives nudges: inferred from the two facts above, not reproduced with a deny config

[iceteaSA]

A constraint for the fix, from the operator side: a child with ctx_reduce denied has only the automatic reclaim left, meaning heuristic drops at execute and emergency drops, so those must stay independent of this verdict.

That's already true today. Outside the prompt surface, the postprocess phase uses ctxReduceAvailability only for the compaction-marker summary's tag prefix (:788, :2315), the permission log (:1419), and the Channel baseline (:2764). transform.ts uses it for prefix skip (:1952) and the channel baseline (:2704). shouldRunHeuristics doesn't read it. Worth a test pinning that once the freeze starts honouring the deny, so a later refactor doesn't gate heuristics on "callable".

[magic-alfonso]

Thanks, confirmed at source on master: the verdict comes only from the first user message's tools map (ctx-reduce-availability.ts:150, failing open to callable), and the live permission read (resolveToolPermissionDenied) only feeds the log at transform-postprocess-phase.ts:1513. So an agent or session that denies ctx_reduce through permissions still gets tags, the reduce guidance and both nudge channels, and a restart doesn't change it.

Your point about reclaim is right too: heuristic and emergency drops don't read this verdict, and that has to stay true once the deny is honoured, so the fix will pin it with a test. We're finishing a release now; this one follows right after it.

[magic-alfonso]

Fixed on master; it ships in the next release. Magic Context now reads the agent's and the session's OpenCode permissions once, before the ctx_reduce availability verdict freezes. If either denies ctx_reduce, the session gets no tags, no reduce guidance and no reduce reminders. A permission change after that point is logged but doesn't flip the verdict, because flipping would rewrite the cached prompt. After a restart the verdict is read again, so a session whose permissions changed pays one cache rebuild then. As you asked, heuristic and emergency drops don't depend on this verdict, and tests fail if either path starts reading it.

Two scope notes: this covers OpenCode 1. On OpenCode 2 the plugin has no client to read agent permissions with, so it keeps today's behaviour there. Pi has no per-agent permission model, so nothing changes on Pi.