Feature request: opt-in to allow /compact (built-in) in scheduled task prompts — capability removed by v2.1.196 restriction

Feature request

Provide an explicit opt-in that allows selected built-in commands — /compact in particular — to execute when fired from a scheduled task (CronCreate) prompt, restoring a capability that existed through v2.1.183 and was removed by the v2.1.196 restriction.

Background / what changed

The scheduled-tasks docs state (forward-documented, not in the v2.1.196 release notes):

As of v2.1.196, a scheduled fire only runs skills that Claude is allowed to invoke on its own. The following reach Claude as plain text instead of executing: built-in commands such as /permissions, /model, or /clear […]

Before that change, a one-shot scheduled prompt of the form /compact <tailored retention guidance> executed the built-in. We used this in a long-running monitoring session: when live context exceeded a self-imposed threshold (~400k tokens), the model composed retention guidance and scheduled a one-shot cron ~90s out; the fire compacted the session (statusline dropped to 0.0k/1000.0k).

Evidence (session JSONL forensics)

• Works on v2.1.183: sessions running 2.1.183 show compact_boundary events with compactMetadata.trigger: "manual" near-daily from 2026-06-16 through 2026-07-07 (last success 2026-07-07T19:43:36Z), each following a cron-fired /compact prompt, including multi-week unattended stretches.
• Broken on ≥v2.1.204 (first post-restriction session launch on this machine; still broken on 2.1.211): the one-shot fires on time, but the /compact … text arrives in the model's context as a plain user message. Controlled test on 2.1.211 (2026-07-16): context tokens 473,636 before the fire → 490,837 after — no compaction, and the failed prompt itself added tokens.
• The break was silent: nothing in release notes, no error at fire time, and long-running sessions keep their launch binary — so the regression only surfaced when a new session eventually launched on a post-2.1.196 build.

Why it matters

• Default auto-compact triggers only near the context ceiling. Long-running, mostly-idle agent sessions (monitors, schedulers) benefit greatly from earlier, retention-tailored compaction at a user-chosen threshold.
• After v2.1.196 there is no programmatic path at all to initiate compaction: hooks (PreCompact) can only block, custom command files cannot invoke built-ins, and the auto-compact threshold is not configurable.
• The only workaround is pinning v2.1.195 with DISABLE_AUTOUPDATER=1, which forgoes all subsequent fixes.

Suggested shape (any of these would work)

1. A settings allowlist, e.g. "scheduledTasks": { "allowedBuiltins": ["/compact"] } — off by default, so the v2.1.196 injection-hardening posture is preserved unless the user explicitly opts in.
2. Alternatively (or additionally): make the auto-compact threshold configurable, which would remove our need to trigger /compact from schedules at all.

We understand and support the security motivation behind the v2.1.196 change (a prompt-injected scheduled task shouldn't run arbitrary built-ins). /compact with an explicit user opt-in seems like a low-risk carve-out: it destroys no data, changes no settings, and only summarizes the session's own context.

Environment

• macOS (Darwin 24.6.0), native install, auto-updates on
• v2.1.183 (works) → v2.1.204 / v2.1.211 (restricted)