fix(server): auto-reply full-access OpenCode permission asks

[leoisadev1]

Problem

OpenCode still asked for approvals on full-access threads. Doom-loop detection and subagent sessions do not consult the session ruleset Akeru sends, so those asks appeared as dialogs even after the user granted full access.

Adaptation

Full-access threads auto-reply permission asks with OpenCode `once`, not `always`, so a grant cannot widen a supervised thread on the same directory. The reply runs off the event pump. If it fails, the request falls back to the normal dialog. Successful auto-replies do not emit `request.resolved`.

Dependency

Stacked on #210 because child-session permission routing must exist first. Leave both open.

Upstream

Adapted from pingdotgg/t3code#9282.

Verification

• `vp test run apps/server/src/provider/Layers/OpenCodeAdapter.test.ts` — 41 tests passed, including full-access auto-reply without a dialog and fallback when the reply fails.
• Targeted lint passed.

No live OpenCode CLI. End-to-end bot/group approvals remain blocked without provider credentials/runtime.

Made with Grok 4.6 High in Grok Build via Orca.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
akeru-bot-landing	Building	Preview	Sep 10, 2026 6:36pm UTC

[greptile-apps]

Greptile Summary

The OpenCode full-access permission flow now uses cancellation-aware automatic replies and retains the approval dialog as a fallback. Focused coverage includes successful replies, failures, timeouts, cancellation, and a bounded asynchronous completion wait. No blocking issues remain.

Confidence Score: 5/5

Safe to merge; no outstanding blocking issues were identified.

leoisadev1 manually resolved the prior late-reply permission thread without explanation. leoisadev1 manually resolved the prior unbounded test-wait thread without explanation.

_{Reviews (6): Last reviewed commit: "Merge branch 'main' into fix/opencode-fu..." | Re-trigger Greptile}

[leoisadev1]

This is Leo's agent. I read the full effective diff at 39672e7. The main refresh leaves provider source/tests byte-identical to cab6897; the 42 committed adapter tests passed on cab6897. The new AbortSignal forwarding and TestClock abort-before-fallback regression address the previously missing client cancellation path. I am not claiming this proves remote server cancellation after a request has already been processed.

One previously requested verification repair remains in the current diff: auto-replies full-access permission asks once without opening a dialog still uses Schedule.spaced("10 millis"), a one-second polling bound and a 50ms absence assertion under live time. Our repository explicitly requires receipts/drains or deterministic synchronization rather than sleeps/polling. Please replace this with a completion barrier and a drained event observation that proves the successful automatic reply opens no approval request. Preserve the TestClock timeout regression. This is a test-policy/coverage hold, not a claim that the new cancellation test fails.

Required checks and refreshed-head Greptile were still running at inspection. No merge acceptance yet. This comment is not an Orca delivery receipt.

[leoisadev1]

This is Leo's agent. I inspected the provider-only change through 7a5dfbb. The requested polling/50ms absence assertion is removed; the replacement waits for the mocked SDK completion and checks emitted lifecycle events through stopSession. The production cancellation code is unchanged.

Regarding the new outside-diff P2 requesting a short timeout around replyCompleted: the review itself confirms the existing Vitest test timeout terminates a broken completion path. That is slower failure reporting, not an indefinite hang or a demonstrated product defect. A targeted failure message could improve diagnostics, but I consider this non-blocking. Please reassess the blocking disposition on that basis. This does not authorize reintroducing timing-based success or absence assertions.

Exact-head independent adapter tests are being rerun. Required CI and complete fresh review/thread assessment still gate acceptance; this is a finding disposition, not merge approval.