Desktop 1.18.4: Settings "Auto-accept permissions" is disconnected from runtime auto-accept (toggle ON still prompts) #38154

Summary

OpenCode Desktop's Settings → General → "Auto-accept permissions" control is broken / misleading on v1.18.4 (macOS arm64).

There are two separate problems that combine into one user-facing failure:

1. Persistence / settings-store bug family (already reported across several issues): the Settings toggle either won't flip, won't stick across restart/workspace changes, or requires hand-editing default.dat.
2. Runtime disconnect (main finding on 1.18.4): even when settings.permissions.autoApprove is successfully set to true and the Settings UI shows the switch ON, permission prompts still appear because the live auto-accept engine does not read that settings field.

In short: the Settings toggle looks like a global "auto-approve all tool permissions" switch, but the runtime auto-accept path is a different store (session/directory autoAccept map). The Settings value is not wired into shouldAutoRespond().

Environment

Expected behavior

1. Turning Settings → General → Auto-accept permissions ON should:
   • persist across app restarts
   • cause subsequent tool permission prompts to be auto-approved (or clearly document that this setting is only a default and that a separate session/directory auto-accept must also be enabled)
2. When the toggle is ON and persisted as "permissions":{"autoApprove":true}, users should not continue to get blocking permission modals for ordinary tool calls unless an explicit deny rule exists.
3. If the Settings toggle is intentionally only a default / not runtime-authoritative, the UI copy should say so (today it reads like a working global switch).

Actual behavior

A) Settings toggle does not reliably control runtime approvals

After forcing persistence so the Settings UI shows Auto-accept permissions = ON, a session still showed a blocking permission modal:

• Title: Permission needed
• Prompt: Run shell command
• Command: wezterm start --cwd <home>
• Actions shown: Always allow / Reject / Allow once
• Workspace context: <home> (home)

So the global Settings switch being ON did not suppress the prompt.

B) Persistence is fragile (same family as prior reports)

Before workaround, default.dat contained:

"permissions":{"autoApprove":false}

Observed symptoms matching prior reports:

• toggle hard to turn on / does not feel sticky
• users resort to quitting the app and hand-editing default.dat

Manual workaround used:

1. Quit OpenCode completely
2. Edit ~/Library/Application Support/ai.opencode.desktop/default.dat
3. Set nested settings.v3 → permissions.autoApprove to true
4. Relaunch

After that:

• Settings UI showed the switch ON
• file still contained "permissions":{"autoApprove":true}
• but permission prompts still appeared

Reproduction steps

Path 1 — UI toggle (common user path)

1. Open OpenCode Desktop 1.18.4 on macOS.
2. Open Settings → General.
3. Toggle Auto-accept permissions ON.
4. Quit and relaunch the app (or switch workspace).
5. Observe either:
   • toggle returns OFF / is not clickable / does not stick, or
   • toggle appears ON but permission prompts still appear for shell/tool calls.

Path 2 — Forced settings persistence (proves runtime disconnect)

1. Fully quit OpenCode.
2. Edit:

~/Library/Application Support/ai.opencode.desktop/default.dat

3. Ensure nested JSON in settings.v3 contains:

"permissions":{"autoApprove":true}

4. Relaunch OpenCode.
5. Confirm Settings UI shows Auto-accept permissions = ON.
6. In a session, trigger a tool that needs approval (example observed: shell command / external terminal launch).
7. Observe: permission modal still appears (Always allow / Reject / Allow once).

Path 3 — Contrast with working auto-accept entry points

Per docs and in-app strings, these do target the runtime auto-accept path:

• TUI/command: Enable auto-approve permissions / command.permissions.autoaccept.enable
• CLI: opencode --auto
• Session/directory auto-accept APIs (enableAutoAccept, toggleAutoAcceptDirectory)

Expected: Settings toggle should either call the same path or clearly not claim to.

Evidence from installed Desktop build (1.18.4 asar)

Inspected /Applications/OpenCode.app/Contents/Resources/app.asar (extracted renderer assets).

1) Settings store has a dedicated field

Default settings include:

permissions: {
  autoApprove: false
}

Getter/setter:

permissions: {
  autoApprove: withFallback(
    () => store2.permissions?.autoApprove,
    defaultSettings.permissions.autoApprove
  ),
  setAutoApprove(value) {
    setStore("permissions", "autoApprove", value);
  }
}

This is what lands in default.dat → settings.v3.

2) Runtime auto-accept uses a different store

Permission runtime methods:

function isAutoAccepting(sessionID, directory) {
  return autoRespondsPermission(store2.autoAccept, sessions(directory), {
    sessionID
  }, directory);
}

function shouldAutoRespond(permission, directory) {
  return autoRespondsPermission(
    store2.autoAccept,
    sessions(directory),
    permission,
    directory
  );
}

Enable path writes store2.autoAccept[key] = true (session key / directory key), then optionally drains pending permissions via permission.list + respondPending.

Event handler only auto-responds on permission.asked when that autoAccept map says so:

const handlePermission = (e2) => {
  const event = e2.details;
  if (event?.type !== "permission.asked") return;
  void respondPending(event.properties, e2.name);
};

3) No bridge found from settings.autoApprove → runtime autoAccept

In the 1.18.4 renderer bundle, settings.permissions.autoApprove / setAutoApprove appear to be settings-persistence only.

Runtime decisions read store2.autoAccept, not settings.permissions.autoApprove.

That explains the user-visible contradiction:

4) UI labels reinforce the wrong mental model

In-app strings present auto-accept as a real runtime mode:

• command.permissions.autoaccept.enable = "Auto-accept permissions"
• toast: "Permission requests will be automatically approved"

Settings exposes a control with the same product language, but it is not clearly scoped as "default only" / "session must still enable".

Related issues (please link / consider consolidating)

This is not an isolated report; it looks like a multi-issue regression cluster around Desktop permissions UX:

Why this issue is still worth a new report: prior issues mostly cover "toggle won't flip/persist". This report adds a stronger claim for 1.18.4:

Even when the persisted settings value is true and the Settings UI shows ON, runtime permission prompts still appear because the Settings field is not the source of truth for auto-response.

Secondary observation (same session; may be separate bug)

While auto-accept was ON in Settings, the agent requested:

wezterm start --cwd <home>

On this machine:

• WezTerm is not installed
• Ghostty is installed (/Applications/Ghostty.app)
• Desktop "Open with" app list in the bundle includes terminal, iterm2, ghostty, warp, etc., and does not list wezterm

So the permission prompt was for launching a terminal app the user does not have. That may be agent/tool choice rather than Desktop open-app integration, but it made the broken auto-accept UX much more alarming ("what is this WezTerm process?").

If useful, happy to split that into a separate issue (prefer installed terminal / Ghostty / configured shell; don't propose missing wezterm).

Impact

• Users cannot trust the Settings switch.
• Workarounds are unsafe/confusing (hand-edit Electron data files).
• Permission prompts continue to block agent flow even after users believe they enabled auto-accept.
• Erodes trust: a prompt for an unknown binary name (wezterm) while auto-accept appears enabled feels like malware, even though WezTerm is a legitimate terminal emulator.

Suggested fix

Minimum correct behavior

1. Wire Settings → Auto-accept permissions into runtime
   • On app/project load, if settings.permissions.autoApprove === true, initialize runtime auto-accept for the active directory/session (same path as enableDirectory / enableAutoAccept).
   • When the Settings toggle changes, call the same enable/disable APIs used by the command palette / session controls.
2. Or, if Settings is intentionally only a default:
   • rename/clarify UI copy
   • show effective runtime state separately ("Session auto-accept: ON/OFF")
   • make the Settings control actually seed new sessions.

Also fix persistence

• Ensure Settings toggle writes settings.v3.permissions.autoApprove reliably under both layout implementations (newLayoutDesigns true/false).
• Prevent silent overwrite back to false on restart/workspace switch.
• Add a regression test: flip toggle → quit → relaunch → value remains true → next permission.asked auto-responds.

Acceptance criteria

• Settings toggle ON persists in default.dat across restart.
• With toggle ON, new permission.asked events for the active workspace are auto-approved (unless explicit deny rules).
• With toggle OFF, prompts still appear.
• Command-palette / CLI --auto / session toggle remain consistent with Settings (or Settings is clearly labeled as default only and still seeds runtime state).
• No dual-store split where UI says ON and runtime stays OFF.

Workarounds for other users (current)

1. Session/runtime auto-accept via command palette:
   • Auto-accept permissions / stop command
   • Desktop keybind users report: Cmd+Shift+A (verify locally; command id permissions.autoaccept)
2. CLI: opencode --auto
3. Config permissions (documented global rules), e.g. project/user config:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "ask",
    "bash": "allow"
  }
}

4. Nuclear/hacky: quit app and set default.dat → settings.v3 → permissions.autoApprove: true
   Note: on 1.18.4 this may only fix the Settings display, not runtime prompts.

Additional local file evidence

default.dat after workaround (outer keys):

{
  "app-version.v1": "{\"version\":\"1.18.4\"}",
  "settings.v3": "{...\"permissions\":{\"autoApprove\":true}...}",
  "highlights.v1": "{\"version\":\"1.18.4\"}"
}

Parsed:

{
  "permissions": {
    "autoApprove": true
  }
}

Despite that value, shell permission modal still appeared for:

wezterm start --cwd <home>

Request

Please treat this as a Desktop permissions source-of-truth bug, not only a toggle persistence nit.

Happy to provide more logs / screen recording if needed. I can also retest a nightly/PR build quickly on this machine.