Summary

After #2524 removed the autoAllowSkills form field from the UI exec-approvals view, the backend config schema at src/gateway/protocol/schema/exec-approvals.ts still declares the field, and three documentation files still describe the feature. The skills marketplace is fully gutted per CLAUDE.md § Fork Context "What's being removed" — this field no longer drives any behavior. Stored values are silently ignored (runtime no longer reads it post-UI-removal).

Scope

In scope:

• Backend schema field (1 line)
• Documentation references (3 files)

Explicitly out of scope (already tracked):

• macOS native app wiring (apps/macos/Sources/RemoteClaw/*.swift) — covered by spike(native): audit Android/iOS/macOS for gutted-feature parallels (deferred per native-release policy) #2527 (spike(native): audit Android/iOS/macOS for gutted-feature parallels (deferred per native-release policy)). The native app has extensive autoAllowSkills threading (9 hits in SystemRunSettingsView.swift, 8 in ExecApprovals.swift, 1 in ExecApprovalEvaluation.swift); those are intentionally deferred under the native-release policy until a coordinated native gut wave runs.

Evidence

Backend schema

src/gateway/protocol/schema/exec-approvals.ts:19:  autoAllowSkills: Type.Optional(Type.Boolean()),

Documentation

docs/tools/exec.md:135:`autoAllowSkills` is a separate convenience path in exec approvals. It is not the same as
docs/tools/exec.md:136:manual path allowlist entries. For strict explicit trust, keep `autoAllowSkills` disabled.
docs/tools/exec-approvals.md:66:    "autoAllowSkills": false
docs/tools/exec-approvals.md:73:      "autoAllowSkills": true,
docs/tools/exec-approvals.md:140:- If you require strict explicit trust, keep `autoAllowSkills: false` and use manual path allowlist entries only.
docs/gateway/security/index.md:188:- **Exec approval drift** (`security=full`, `autoAllowSkills`, interpreter allowlists without `strictInlineEval`): are host-exec guardrails still doing what you think they are?

Why this is safe

• Removing the schema field: existing config values containing autoAllowSkills will be rejected by TypeBox validation unless the schema accepts extra keys. Verify whether the schema currently rejects unknown fields; if it does, add a migration note in the PR.
• Documentation removal: documenting a field that has no effect is misleading. Removal aligns docs with runtime reality.

Changes

1. Backend schema — src/gateway/protocol/schema/exec-approvals.ts:19: delete the autoAllowSkills field from the TypeBox schema. Verify no other schemas reference it.
2. Documentation — revise the three doc files to drop all autoAllowSkills mentions:
   • docs/tools/exec.md — delete the paragraph at lines 135-136
   • docs/tools/exec-approvals.md — remove the field from example JSON at lines 66, 73; rewrite or drop the guidance at line 140
   • docs/gateway/security/index.md:188 — drop the autoAllowSkills mention from the drift-check list (keep security=full and strictInlineEval items)
3. Migration note (optional, only if schema rejects unknown fields on deserialization): add a sentence to the changelog/release notes that stored autoAllowSkills values are now silently ignored on load.

AC

• grep -rn 'autoAllowSkills' src/ docs/ returns zero hits (macOS native excluded per scope)
• pnpm check green (docs drift / docs-lint, if any, passes)
• pnpm test green
• If existing config files in the repo tree carry the field, they are updated (run grep -rn autoAllowSkills across the repo excluding apps/macos/)

Context

Follow-up to #2524 (gut(ui): remove autoAllowSkills from exec-approvals config, merged as #2535 / commit b13e053c7d). The UI PR's scope was intentionally UI-only; this issue tracks the backend and docs half.

Surfaced during batch 20260424-6b79 by the /do #2524 subprocess, which flagged the out-of-scope backend/docs hits in its PR description and recommended a separate follow-up.