feat(core)!: give scheduled jobs their own permission posture

[oratis]

Summary

PR 7 of docs/FLOATBOAT_ADOPTION_PLAN.md §2.E. Completes the security fix #237 deliberately left half-done.

⚠️ BREAKING. An unattended run no longer inherits a permissive permissions.defaultMode. bypassPermissions and acceptEdits are clamped to default unless the job says otherwise.

Why break it

A cron job reads the same settings.json you use interactively. A bypassPermissions chosen for REPL convenience silently became the posture of every job firing at 3am with nobody watching.

Those are different decisions. Choosing "never ask me" while sitting there watching is not the same as choosing it for a run nobody sees. They shouldn't share one switch.

#237 shipped a warning for this and explicitly deferred the clamp, because clamping without an opt-in is just breakage. The opt-in now exists, so the clamp lands with it.

The opt-in

{ "schedule": "0 3 * * *", "prompt": "...", "profile": { "mode": "bypassPermissions" } }

Or via CronCreate's new mode / sandbox arguments. An explicit profile.mode is honoured as written, including a permissive one — that's what makes the clamp a correction rather than a restriction.

Everything else only tightens

Field	Rule
mode	Explicit value wins outright
permissions	Denies and asks union; allows intersect
sandbox	Applied only when stricter than ambient

Same one-way property as the file contract, for the same reason: a mechanism that can only tighten cannot reduce existing safety, whatever a profile author writes. A profile listing allow: ["Read", "Bash"] against ambient allow: ["Read"] yields ["Read"] — there's a test for exactly that.

An unrecognised sandbox value in a hand-edited cron.json is ignored rather than trusted.

The clamp announces itself

[job] mode=default onApprovalRequired=deny
[job] Permission mode "bypassPermissions" was not applied to this unattended run — it is
      inherited from settings and nobody is present to approve. Running as "default".
      Set the job's profile.mode explicitly to opt back in.

A silent clamp is as surprising as a silent grant, just in the other direction.

Migration

Jobs that relied on the inherited bypass need profile.mode set explicitly. The job log names the exact fix on the first run after upgrading, so this surfaces itself rather than failing mysteriously.

Test plan

• pnpm test — 1401 passed, 16 skipped (+16 core)
• pnpm typecheck · pnpm lint · pnpm format:check · pnpm build · node scripts/check-docs.mjs

Area	Cases
Clamp	Both permissive modes clamped; all four non-permissive modes untouched
Opt-in	Explicit permissive profile.mode honoured; a stricter profile mode also wins
Announcement	Clamp message names the mode and the fix; silent when no clamp
One-way permissions	Denies/asks union; allows intersect; a profile cannot introduce an allow ambient lacked; ambient allows survive a deny-only profile; dedupe
One-way sandbox	Takes the stricter; refuses to loosen in both directions; hand-edited garbage ignored, not trusted

Documentation

• docs/quickstart.md — rewrote the scheduled-jobs caveat into "The permission posture of a scheduled job": the clamp, why the two decisions differ, the opt-in table, and the tighten-only rule

Release notes label

• release-notes:breaking — unattended runs stop inheriting permissive modes

Related

Plan §2.E (PR 7). Completes the deferred half of #237. Research: docs/research/floatboat.md §3.1(a) — mechanism borrowed, design entirely our own.

🤖 Generated with Claude Code