Repository navigation
Desktop v1.18.3 — "Auto-accept permissions" settings toggle permanently disabled (cursor: not-allowed) #37617
Description
Description
In OpenCode Desktop 1.18.3, the "Auto-accept permissions" toggle in the Settings dialog is permanently disabled (cursor: not-allowed) regardless of context. Users cannot enable auto-accept through the settings UI, even though the underlying feature works correctly via the TUI command palette (Mod+Shift+A or the permissions.autoaccept command) and the opencode --auto CLI flag.
Environment
- OpenCode Desktop: 1.18.3
- Platform: Windows (likely all platforms)
- Installation:
@opencode-aidesktop(Electron)
Reproduction
- Install OpenCode Desktop 1.18.3
- Open the app (any directory, including new/unused ones)
- Go to Settings -> General tab
- Hover over the "Auto-accept permissions" toggle -> cursor shows
not-allowed - Click the toggle -> no response
Expected behavior
The toggle should be clickable. When enabled, subsequent permission requests should be automatically approved for the current session or directory, matching the behavior of Mod+Shift+A and opencode --auto.
Root cause
The settings dialog has two implementations selected at runtime based on settings.general.newLayoutDesigns:
// openSettings() in main-hem2imez.js
const module = settings.general.newLayoutDesigns()
? await import("./index-CHbW1EYV.js") // New layout (default in 1.18.3)
: await import("./dialog-settings-C3QH-NWT.js"); // Old layout (fallback)When newLayoutDesigns is true (the default in 1.18.3), the new layout is loaded. Both implementations have the same fatal pattern -- the toggle's disabled property is bound to a directory lookup that always fails because no context is passed to the dialog.
New layout (index-CHbW1EYV.js):
const dir = createMemo(() => {
if (!props.sessionID) return void 0; // sessionID is never passed
return serverSync().session.lineage.peek(props.sessionID)?.session.directory;
});
// ...
<Switch
get checked() { return accepting(); }
get disabled() { return !dir(); } // always true
/>Old layout (dialog-settings-C3QH-NWT.js):
const dir = createMemo(() => decode64(params.dir)); // params.dir is never passed
<Switch
get disabled() { return !dir(); } // always true
/>The dialog is instantiated with empty props at the call site:
// main-hem2imez.js line 114429
dialog.show(() => createComponent(x2.DialogSettings, {})); // no sessionID, no dirNo sessionID or dir parameter is passed to the component, so dir() persistently returns undefined and the toggle is permanently disabled.
Meanwhile, the TUI command palette implementation works correctly because it directly accesses the SDK's current working directory:
// command palette handler
const toggleAutoAccept = () => {
const sessionID = params.id;
if (sessionID) permission.toggleAutoAccept(sessionID, sdk().directory);
else permission.toggleAutoAcceptDirectory(sdk().directory);
};Suggested fix
Two possible approaches:
Option A -- Minimal (change disabled + add directory fallback):
- Set
disabled: falseon the Switch so the toggle is always clickable - Add fallback in
toggleAccept()to usetoggleAutoAcceptDirectory(sdk().directory)when nosessionIDis available (mirroring the command palette logic)
Option B -- Structural:
Pass the active session/directory context when opening the settings dialog:
dialog.show(() => createComponent(x2.DialogSettings, {
sessionID: currentSessionID,
dir: base64Encode(sdk().directory)
}));
Activity
github-actions commentedon Jul 18, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct or adds new information (such as the detailed root cause analysis here), consider referencing those issues rather than reopening the same one.
eddiedon commentedon Aug 7, 2026
Still reproducible on Desktop 1.18.15 (Windows,
@opencode-aidesktop). The "Auto-accept permissions" toggle in Settings -> General remains permanently disabled (cursornot-allowed, click does nothing), identical to the 1.18.3 report.Looks like the fix hasn't landed yet, so bumping this for priority.
Workaround that works right now: inside an active chat, press
Ctrl+Shift+A(Mod+Shift+A) to toggle auto-accept for the current session. The runtime feature itself works fine -- only the Settings UI entry point is broken.linghengqian commentedon Sep 4, 2026
6WayPain commentedon Oct 1, 2026
Still reproducible on Desktop v1.18.33 (Windows 11): Settings -> General -> "Auto-accept permissions" toggle remains disabled (
cursor: not-allowed), clicking does nothing.Confirming the workaround from @eddiedon still works: pressing Ctrl+Shift+A inside an active chat toggles auto-accept for the current session (toast confirms auto-accept is active). The runtime feature is fine, only the Settings UI entry is broken.
Also verified: the desktop Command Palette has no "Auto-accept permissions" entry (searching
autoreturns no results) - that entry only exists in the TUI.neriousy commentedon Oct 1, 2026
Closing as a duplicate of #31137. Same bug: the "Auto-accept permissions" toggle is disabled in the new layout because the settings dialog has no project context. Tracking in #31137.