Skip to content

Disambiguate "auto" permission mode from Claude Code auto mode (label as "accept edits")#556

Open
bborn wants to merge 1 commit into
mainfrom
task/4090-feedback-claude-confuses-auto-accept-edi
Open

Disambiguate "auto" permission mode from Claude Code auto mode (label as "accept edits")#556
bborn wants to merge 1 commit into
mainfrom
task/4090-feedback-claude-confuses-auto-accept-edi

Conversation

@bborn
Copy link
Copy Markdown
Owner

@bborn bborn commented Jun 5, 2026

What & why

Kyle reported that the word "auto" is overloaded in TaskYou's permission
settings (#tmp-taskyou-feedback):

I think Claude got confused on the auto mode because you might have used the
word "auto" originally to refer to the "accept edits" mode (before CC auto
mode was a thing). So in this case there's actually 4 permission sets.
--enable-auto-mode makes it available in CC.

TaskYou's auto permission set predates Claude Code's own auto mode (the
agentic flow gated by --enable-auto-mode). Our auto actually maps to
Claude's acceptEdits (--permission-mode acceptEdits): auto-accept file
edits while still prompting for risky actions. Reusing the word "auto" for that
made both agents and users conflate it with CC's separate auto mode.

This PR keeps the three permission sets TaskYou exposes (prompt / accept-edits /
dangerous) but renames the user- and agent-facing label from "auto" to
"accept edits"
everywhere, and documents in code why CC's --enable-auto-mode
is a distinct fourth mode we do not surface.

Changes

  • UI: settings form option Auto → Accept Edits, detail badge AUTO → ACCEPT EDITS,
    queue/confirm prompt "execute in accept-edits mode".
  • CLI: --permission-mode help + queue notifications use accept-edits
    (with auto noted as a legacy alias).
  • MCP: permission_mode schema advertises accept-edits and the description
    explicitly states it is NOT Claude Code's --enable-auto-mode; enum is
    ["default", "accept-edits", "dangerous"].
  • Back-compat (no migration): NormalizePermissionMode now accepts
    accept-edits / accept_edits / acceptEdits (case- and space-insensitive),
    all mapping to the canonical stored value "auto". Existing DB rows, scripts,
    and --permission-mode auto keep working.
  • Code comments on PermissionModeAuto / NormalizePermissionMode spell out the
    history so this doesn't get re-confused.

Tests

  • internal/db: NormalizePermissionMode covers the new aliases + trimming/case.
  • internal/executor: accept-edits resolves to --permission-mode acceptEdits.
  • go build ./..., go vet, and all affected package tests pass.

QA evidence

Rendered against an isolated ty instance (VHS, real TUI).

Settings → Default Permission Mode — "Accept Edits" replaces the overloaded "Auto":

settings-permission-mode

Detail header badge — active accept-edits task now shows ACCEPT EDITS (was AUTO):

detail-accept-edits-badge

(The "Claude failed to start" line in the full-screen capture is just the
isolated QA harness having no live tmux agent — unrelated to this change.)

🤖 Generated with Claude Code

TaskYou's "auto" permission set predates Claude Code's own "auto mode"
(the agentic flow gated by --enable-auto-mode). Our "auto" actually maps
to Claude's acceptEdits (--permission-mode acceptEdits): auto-accept file
edits while still prompting for risky actions. Reusing the word "auto" for
that made agents and users conflate it with CC's separate auto mode — the
4-permission-set confusion Kyle reported.

Surface this mode everywhere as "accept edits" / "accept-edits" instead:
- Settings form, detail badge (AUTO -> ACCEPT EDITS), and queue/confirm
  prompts now read "accept edits".
- CLI --permission-mode help + notifications and the MCP permission_mode
  schema describe it as accept-edits and explicitly note it is NOT
  --enable-auto-mode; "auto" is documented as a legacy alias.
- NormalizePermissionMode now accepts "accept-edits"/"acceptEdits" (and is
  case/space-insensitive), all mapping to the canonical "auto" value, so
  stored rows, old CLI calls, and scripts keep working with no migration.

Code comments spell out why the stored value stays "auto" for back-compat.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant