feat: support `auto` (and `dontAsk`) permission modes from @anthropic-ai/claude-agent-sdk

[fintorq]

Summary

The Claude Agent SDK (@anthropic-ai/claude-agent-sdk@^0.2.96, which happy already depends on) supports six PermissionMode values:

// node_modules/@anthropic-ai/claude-agent-sdk/sdk.d.ts:1489
export declare type PermissionMode =
    'default' | 'acceptEdits' | 'bypassPermissions' | 'plan' | 'dontAsk' | 'auto';

Happy currently only plumbs through the first four (plus Codex-specific read-only | safe-yolo | yolo). The newer auto mode (model decides whether to prompt) and dontAsk (SDK auto-approve without prompts) are not reachable from the app.

Side note: dontAsk is already listed in packages/happy-app/sources/components/modelModeOptions.ts:52 and its i18n strings, but the wire enum in packages/happy-wire/src/messageMeta.ts rejects it — so even selecting it in the UI fails validation before reaching the CLI. dontAsk is effectively dead UI today.

User impact

Users on recent Claude Code versions cannot select the auto mode that the CLI natively offers. They are stuck choosing between hard bypass (bypassPermissions) and default prompting, with no middle-ground model-driven behavior. The half-wired dontAsk is also a papercut.

Proposed implementation path

Changes isolated to Happy — no SDK change needed.

1. packages/happy-wire/src/messageMeta.ts: add 'auto' (and 'dontAsk' if we're also finishing that feature) to the permissionMode zod enum.
2. packages/happy-cli/src/api/types.ts:35: extend PermissionMode union to include 'auto'. Update doc comment.
3. packages/happy-cli/src/claude/utils/permissionMode.ts:
   • Add 'auto' to VALID_PERMISSION_MODES.
   • mapToClaudeMode: auto is identity passthrough (SDK native).
4. packages/happy-cli/src/claude/runClaude.ts:80: ensure dangerouslySkipPermissions is NOT set for auto (should only cover bypassPermissions / yolo / sandbox).
5. packages/happy-cli/src/claude/utils/permissionHandler.ts: no new branch needed at handleToolCall — auto should fall through to the SDK's own gating (i.e. canCallTool runs normally; what matters is the mode value passed to the SDK).
6. packages/happy-cli/src/codex/executionPolicy.ts: add defensive mapping for Codex fallback (e.g. auto → approvalPolicy: 'on-request', sandbox: 'workspace-write'), or leave on defaults.
7. packages/happy-app/sources/components/modelModeOptions.ts:48: add { key: 'auto', name: translate('agentInput.permissionMode.auto'), ... } to getClaudePermissionModes.
8. packages/happy-app/sources/text/_default.ts + all translations/*.ts: add agentInput.permissionMode.auto strings.

Release coordination

happy-wire ships as a separate npm package that happy-server also depends on. Adding values to the permissionMode enum is a coordinated release: clients sending 'auto' to a server with the old enum will be rejected at validation. Sequence: publish wire, upgrade server, then ship CLI + app simultaneously (or gate the UI option behind a feature flag until rollout is complete).

Acceptance criteria

• User can select auto in the Claude permission-mode selector on mobile/web.
• Outbound messages carry meta.permissionMode: 'auto'.
• CLI forwards to the Claude SDK as permissionMode: 'auto' and session behaves as native Claude Code auto mode.
• --permission-mode auto via claudeArgs is also honored.
• No regression for the existing 7 modes.

Out of scope

• Finishing dontAsk end-to-end — can ride with this PR or split; I'd suggest same PR for consistency since the plumbing is identical.
• Gemini / Codex native auto support — neither agent has it natively; only defensive mapping is required.

Related

• SDK type reference: @anthropic-ai/claude-agent-sdk@0.2.96 → sdk.d.ts:1489
• Breaking changes in Claude Code 2.0.25 #450 Breaking changes in Claude Code 2.0.25 (version context)

[dos1989]

For anyone picking this up: I drafted a scoped PR covering just the `dontAsk` half of the enum drift — see #1174 (now closed, branch kept at https://github.com/dos1989/happy/tree/fix/dontask-permission-mode for reference).

It covers:

• `happy-wire`: add `'dontAsk'` to `MessageMetaSchema.permissionMode` + README
• `happy-cli`: extend `PermissionMode` union, `MessageMetaSchema` enum, `VALID_PERMISSION_MODES`, internal `QueryOptions.permissionMode` (matches SDK 0.2.96)
• `happy-cli` `PermissionHandler`: treat `'dontAsk'` like `'bypassPermissions'` in `canCallTool` (auto-allow, no prompt)
• `happy-app`: add `'dontAsk'` to `typesRaw` mirror enum
• Unit tests updated (18/18 pass)

Closed because it's server-coordinated — without the matching `happy-server` update the client changes alone don't unblock end users, and `auto` mode (the other half of this issue) isn't covered. Happy to revive and re-scope once a maintainer signals intent + is ready to bundle the server-side bump.

Additional context I ran into while investigating:

1. Current user-facing failure mode is hard (not silent). When a user picks `dontAsk` in the Claude permission-mode UI, the server's Zod validation on `meta.permissionMode` rejects the whole message payload — the user's prompt never reaches Claude at all. This is strictly worse than a silent fallback to `default`; today this option is an active footgun, not just a no-op.
2. `PermissionModeSelector` renders no label (`packages/happy-app/sources/components/PermissionModeSelector.tsx:64-66` — only a hammer icon + empty ``). Combined with the `dontAsk` footgun, users can cycle to a broken mode without any visible indication of which mode is active. Probably worth a separate small PR.
3. Workaround for users blocked today: start `happy-cli` with `--dangerously-skip-permissions` or `--permission-mode bypassPermissions`. Initial mode is set at startup (`packages/happy-cli/src/claude/utils/permissionMode.ts:80-88`); if the iOS client sends `dontAsk` and the server drops the message, the CLI never overwrites `currentPermissionMode`, so bypass persists.

[Flipper916Gpro]

Summary

The Claude Agent SDK (@anthropic-ai/claude-agent-sdk@^0.2.96, which happy already depends on) supports six PermissionMode values:

// node_modules/@anthropic-ai/claude-agent-sdk/sdk.d.ts:1489
export declare type PermissionMode =
    'default' | 'acceptEdits' | 'bypassPermissions' | 'plan' | 'dontAsk' | 'auto';

Happy currently only plumbs through the first four (plus Codex-specific read-only | safe-yolo | yolo). The newer auto mode (model decides whether to prompt) and dontAsk (SDK auto-approve without prompts) are not reachable from the app.

Side note: dontAsk is already listed in packages/happy-app/sources/components/modelModeOptions.ts:52 and its i18n strings, but the wire enum in packages/happy-wire/src/messageMeta.ts rejects it — so even selecting it in the UI fails validation before reaching the CLI. dontAsk is effectively dead UI today.

User impact

Users on recent Claude Code versions cannot select the auto mode that the CLI natively offers. They are stuck choosing between hard bypass (bypassPermissions) and default prompting, with no middle-ground model-driven behavior. The half-wired dontAsk is also a papercut.

Proposed implementation path

Changes isolated to Happy — no SDK change needed.

1. packages/happy-wire/src/messageMeta.ts: add 'auto' (and 'dontAsk' if we're also finishing that feature) to the permissionMode zod enum.
2. packages/happy-cli/src/api/types.ts:35: extend PermissionMode union to include 'auto'. Update doc comment.
3. packages/happy-cli/src/claude/utils/permissionMode.ts:
   • Add 'auto' to VALID_PERMISSION_MODES.
   • mapToClaudeMode: auto is identity passthrough (SDK native).
4. packages/happy-cli/src/claude/runClaude.ts:80: ensure dangerouslySkipPermissions is NOT set for auto (should only cover bypassPermissions / yolo / sandbox).
5. packages/happy-cli/src/claude/utils/permissionHandler.ts: no new branch needed at handleToolCall — auto should fall through to the SDK's own gating (i.e. canCallTool runs normally; what matters is the mode value passed to the SDK).
6. packages/happy-cli/src/codex/executionPolicy.ts: add defensive mapping for Codex fallback (e.g. auto → approvalPolicy: 'on-request', sandbox: 'workspace-write'), or leave on defaults.
7. packages/happy-app/sources/components/modelModeOptions.ts:48: add { key: 'auto', name: translate('agentInput.permissionMode.auto'), ... } to getClaudePermissionModes.
8. packages/happy-app/sources/text/_default.ts + all translations/*.ts: add agentInput.permissionMode.auto strings.

Release coordination

happy-wire ships as a separate npm package that happy-server also depends on. Adding values to the permissionMode enum is a coordinated release: clients sending 'auto' to a server with the old enum will be rejected at validation. Sequence: publish wire, upgrade server, then ship CLI + app simultaneously (or gate the UI option behind a feature flag until rollout is complete).

Acceptance criteria

• User can select auto in the Claude permission-mode selector on mobile/web.
• Outbound messages carry meta.permissionMode: 'auto'.
• CLI forwards to the Claude SDK as permissionMode: 'auto' and session behaves as native Claude Code auto mode.
• --permission-mode auto via claudeArgs is also honored.
• No regression for the existing 7 modes.

Out of scope

• Finishing dontAsk end-to-end — can ride with this PR or split; I'd suggest same PR for consistency since the plumbing is identical.
• Gemini / Codex native auto support — neither agent has it natively; only defensive mapping is required.

Related

• SDK type reference: @anthropic-ai/claude-agent-sdk@0.2.96 → sdk.d.ts:1489
• Breaking changes in Claude Code 2.0.25 #450 Breaking changes in Claude Code 2.0.25 (version context)

[atwoodwang]

I really need Happy to support Claude Code's auto permission mode.

Right now my workflow starts in local mode with auto enabled, but as soon as I take over the session from the mobile app and Happy switches the session to remote mode, auto mode appears to stop working. After that, almost every command asks for approval again.

This makes the local -> remote handoff much more painful, especially when I'm trying to continue work from my phone. Auto mode is the right middle ground for me: I don't want full yolo/bypass all the time, but I also can't approve every single command while using Happy remotely.

Please consider supporting and preserving auto mode across the local-to-remote transition. It would make the Happy mobile experience much smoother.

[Mingyang0624]

Confirmed — and it's worse than a dead-UI papercut: selecting "Don't ask again" makes the CLI silently drop every user message.

Repro (happy-coder 1.1.9 from npm, native Windows 11, current Android app as of 2026-07-04, daemon-spawned remote session):

1. In the app, set the session's permission mode to "Don't ask again" (dontAsk).
2. Send any message.
3. Session stays "online", no reply ever comes, and there is no error anywhere — the session process just sits in Waiting for messages....

What happens in the shipped bundle (dist/types-*.mjs / .cjs):

• The app attaches meta: { permissionMode: "dontAsk", model: "opus", effort: "max", ... } to each message.
• routeIncomingMessage() validates with UserMessageSchema.safeParse(message). The meta schema's enum is z.enum(["default","acceptEdits","bypassPermissions","plan","read-only","safe-yolo","yolo"]), so the parse fails, the function falls through past the file-event branch, and the user message is discarded with no warning log and no NACK back to the app.

Session log ends exactly at the receive:

[14:15:22.069] [MessageQueue2] Waiting for messages...
[14:21:07.280] [SOCKET] [UPDATE] Received update:
 { "role": "user", "content": { ... },
   "meta": { "sentFrom": "android", "permissionMode": "dontAsk", "model": "opus", "effort": "max" } }
(nothing after this — message dropped)

• The bundled claude binary (2.1.141) already accepts both modes natively:

error: option '--permission-mode <mode>' argument 'bogus' is invalid.
Allowed choices are acceptEdits, auto, bypassPermissions, default, dontAsk, plan.

Locally patching the dist enum to add "dontAsk" / "auto" fixes it end to end on the same machine: the message flows, claude spawns and replies (verified via the spawned process args showing --permission-mode auto after mapping, model passthrough intact).

Two asks on top of the proposal above:

1. Please treat this as a bug, not only a feature request — any safeParse failure on an incoming user message in routeIncomingMessage should at least log a warning. Silent user-message loss with an "online" session is brutal to debug.
2. This is the same schema-drift family as effort selection never reaches Claude — effort missing from MessageMetaSchema (stripped by Zod) #1375 (effort stripped by Zod). A shared wire-schema version handshake between app and CLI would prevent this whole class.

[nashiki]

First of all — thank you for building Happy. I use it every single day, and it has genuinely become part of my life rather than just a tool. Being able to keep a Claude Code session going from my phone, away from the desk, changed the way I work. I'm really grateful to the maintainers for making this and giving it away.

I just wanted to leave a quiet +1 here as a user.

All I can say from my side is this: if auto mode became selectable in Happy, my daily walks and jogs with Happy would be even more enjoyable. Today I find myself choosing between approving every single step on a small screen while walking, or switching approvals off entirely. auto feels like the mode that would let me relax and just keep walking.

No pressure on the timing at all — I know you have a lot on your plate. I simply wanted you to know that someone far away in Japan is looking forward to it. Thank you again for everything you do.