Files

T

Bohdan Triapitsyn 0202e88eb4 fix(vscode): restore permission auto-accept parity

Add a VS Code-specific foreground permission responder while preserving the server-owned implementation for web, desktop, and mobile runtimes.

Persist the authoritative VS Code policy in extension global state and expose matching GET/PUT bridge routes. Broadcast policy updates to the sidebar, session editor panels, and agent manager so every active webview observes the same explicit per-session policy.

Resolve missing child-session lineage through OpenCode, honor nearest explicit ancestor overrides, deduplicate concurrent requests, retry transient replies, and reconcile pending permissions after enablement, bootstrap, and reconnect. Treat resolved requests as handled and route notification suppression through the same responder outcome.

Keep post-toggle reconciliation failures non-fatal after policy persistence and fail closed when lineage or replies cannot be confirmed. Document that auto-accept intentionally cannot run while every OpenChamber webview is closed or suspended.

2026-07-17 12:59:41 +03:00

2.1 KiB

Raw Blame History

Permission Auto-Accept

Purpose

This module owns the authoritative permission auto-accept policy for web, desktop, and mobile runtimes. Policy is persisted in OpenChamber settings so permission handling survives UI disconnects and server restarts.

Policy

permissionAutoAccept.sessions contains explicit per-session boolean policies.

Policy inheritance uses the nearest explicit session value. A child false therefore overrides a parent true; descendants without an explicit value inherit from their nearest configured ancestor.

Runtime

createPermissionAutoAcceptRuntime loads and serializes policy writes, subscribes to the global OpenCode event hub, caches session lineage, retries transient replies, and reconciles pending permissions after startup, reconnect, and policy enablement. Enabling Auto-Accept for a session immediately accepts matching pending requests and keeps handling future requests without requiring a connected UI.

Unknown lineage and failed policy loads fail closed. A failed pending-permission fetch is distinct from an empty successful response and never clears policy state.

Routes

GET /api/permission-auto-accept
PUT /api/permission-auto-accept/sessions/:sessionId

These are normal authenticated OpenChamber runtime routes. They must not be added to browser URL-token allowlists.

UI ownership

packages/ui/src/stores/permissionStore.ts is a projection of server policy and does not persist an independent policy. The server is the sole responder and the UI renders pending requests until the authoritative permission.replied event arrives.

VS Code retains its foreground-only responder because it does not run the web server runtime. Its extension host persists and broadcasts the authoritative policy across webviews, while the active UI handles live events plus startup, reconnect, and enablement reconciliation. With all OpenChamber webviews closed or suspended, permissions are not auto-accepted; this is an intentional VS Code limitation.

Tests

runtime.test.js covers restart persistence, nearest explicit subagent inheritance, missing-lineage lookup, retry/deduplication, and reconnect reconciliation.

2.1 KiB Raw Blame History