[yan-ad]

Summary

• Add --auto as a global alias for automatic permission approval.
• Support both crabcode --auto and crabcode acp --auto (flag before or after acp).
• Preserve explicit deny rules, disabled tools, and agent restrictions.
• Carry auto mode through ACP new, load, resume, and fork sessions.
• Document the mode and add offline real-process regression coverage.

Verification

• cargo test --locked -- --test-threads=1
• cargo test --release --locked --test auto_permissions -- --test-threads=1
• bun test scripts/release-workflow.test.ts npm/install.test.js remote-client/tests
• bash scripts/check-aisdk-boundary.sh
• cargo fmt --all -- --check

All checks passed.

[Blankeos]

feat/auto-permissions → main
Model: claude-sonnet-5-5, effort unknown

Confidence: 4.5/5

The change is small and well targeted, reuses the existing dangerously_skip_permissions mechanism, and the new real-process tests prove the behavior offline. The remaining doubts are about scope and merge ordering, not correctness.

Checks run (worktree of the PR head, separate target dir):

• cargo fmt --check: clean.
• cargo build: OK.
• cargo test -- --test-threads=1 (whole suite): 1853 passed / 0 failed / 3 ignored (unit), tests/acp_stdio.rs 7 passed, tests/auto_permissions.rs 6 passed.
• cargo clippy --all-targets: no warnings in lines this PR adds (the ones in the touched files are pre-existing).
• Mergeability: GitHub says MERGEABLE/CLEAN; a local git merge-tree against current origin/main (4c08ae6) merges with no conflicts.
• Real CLI: crabcode --help and crabcode acp --help list [aliases: --auto, --yolo]; --auto acp and acp --auto both parse; --auto --yolo together errors with "cannot be used multiple times" (same as the old --yolo --dangerously-skip-permissions, fine).
• The new integration tests spawn the real binary against a local mock OpenAI-compatible server (random port, no credentials): ACP with --auto before/after acp writes the file with zero session/request_permission requests; without --auto a permission request is sent and a rejection is honored; an explicit config deny is still enforced under --auto; auto mode survives close/load/resume/fork; print mode with --auto runs a configured ask rule. I read the test code and it does assert these things (not just that the process starts).

Screenshot (help output, the only user-visible surface; the permission behavior is covered by the process tests above, there is no new TUI):

Confidence bumps: none left. (Real provider/editor end-to-end with Zed or similar needs credentials and an editor; it would only move 4.5 to 5.)

Summary

Adds --auto as a visible alias of --dangerously-skip-permissions (alongside --yolo) and makes the flag global = true so it works before or after acp. The flag is threaded from main through acp::run -> AcpService::new -> configured_tool_permissions, so ACP new/load/resume/fork sessions all get .dangerously_skip_permissions(true). Explicit deny rules, disabled tools and agent (plan) restrictions still win. README gets an "Auto-approve Permissions" section. Previously the flag was silently ignored for crabcode acp; now it is honored.

Map

flowchart TD
  main["main.rs: Args flag (alias auto, global)"] --> acp_mod["acp/mod.rs + server.rs: pass bool"]
  acp_mod --> svc["acp/service.rs: AcpService.dangerously_skip_permissions"]
  svc --> perms["configured_tool_permissions (new, load, resume, fork)"]
  perms --> tp["tools::ToolPermissions (existing)"]
  main --> rt["config/runtime.rs: doc comment only"]
  tests["tests/auto_permissions.rs (new, 535 lines)"] -.-> main
  tests2["tests/acp_stdio.rs + chat.rs test: hermetic fixes"] -.-> svc

Loading

Start in src/acp/service.rs (configured_tool_permissions), then tests/auto_permissions.rs.

Regressions

• Behavior change outside --auto: configured_tool_permissions now also calls .with_global_tool_config(config.merged_config.tools.clone()). So in ACP, tools disabled via the config tools map (e.g. bash: false) are now actually enforced even without --auto. That is consistent with the TUI path (config/runtime.rs does the same) and is probably a real fix, but it is not mentioned in the PR description and existing ACP users who had a disabled tool that was silently usable will see it stop working. Worth a line in the description/changelog.
• global = true means crabcode serve --auto, attach --auto, jobs --auto, upgrade --auto etc. now parse and silently ignore the flag (before they errored as unknown). Only the main/print/acp paths read it. Low risk, but a user may assume serve --auto does something. Consider documenting or rejecting for those subcommands.
• Renaming the primary flag help text now says "interactive, print, and ACP modes"; the --dangerously-skip-permissions name is kept, so no break for existing scripts.
• Scope creep (benign): tests/acp_stdio.rs (switches to effective_catalog.json fixture, env_remove("CRABCODE_TEST_MODE"), a Drop that kills the child) and a hard-coded /Users/carlo/... path in a chat.rs test. These are test hermeticity fixes that look necessary to make the suite pass on other machines; they inflate the diff but do not touch production code.
• Safety note: auto also skips the "external directory" prompts, which the new unit test verifies and the README warns about. Intended.

Migrations

None.

Before merging

• Mention the with_global_tool_config ACP behavior change in the PR description (or split it out)
• Decide whether --auto on serve/attach/jobs/upgrade should be rejected rather than silently ignored
• Merge ordering: this touches src/acp/service.rs, tests/acp_stdio.rs, src/main.rs, README.md, which also overlap open PRs refactor(acp): split oversized service into focused modules #67 (splits service.rs into modules, will conflict hard with whichever lands second), fix(acp): keep sessions usable after provider failures #72, fix(acp): trigger automatic compaction from provider context usage #64, feat(auth): add Google Antigravity browser OAuth #70 (service.rs/acp_stdio/main.rs/README), feat(plugin): add OpenCode compatibility host #25 (main.rs) and feat(cli): polish installation and upgrade progress UI #66 (README). Currently conflict-free with main; the service.rs hunks will need re-applying if refactor(acp): split oversized service into focused modules #67 lands first