--dangerously-run-scripts runs a runtime rule's check.ts (arbitrary code) with no server verification. Today it is accepted in any context, so an agent that hits a withheld or unverified runtime rule can add the flag to get a green run and carry on. #406 tells the check and ci recipes not to do that, but a recipe is advice and the flag is the gate.
Proposal
Accept the flag only when a human is plausibly present or the caller has declared a CI context:
process.stdin.isTTY (or stdout) is true, orCI=1 / CI=true is set.
Otherwise refuse with a coded error (e.g. UNSAFE_FLAG_REQUIRES_TTY) that says why, so an agent stops and asks the user instead of retrying. The refusal must happen before any check.ts is loaded.
Where the flag is accepted today
taskless check (commands/check.ts, plan via rules/runtime/plan.ts)taskless test / verify (commands/verify.ts, rules/inspect.ts)taskless demo (commands/demo.ts)
Recipes that must change with it
agent/create-runtime-rule.md tells an agent to run test .taskless/rules/runtime/<name> --dangerously-run-scripts as an ordinary authoring step (line ~104), and agent/verify-rule.md offers the flag as an alternative to a blessed signature. Under this gate an agent in a non-TTY shell without CI is refused at that step, which is the intent, so the recipe needs to say "ask the user to run this, or to confirm" instead.
Open question
Whether CI=1 should be enough on its own, or whether CI should also need an explicit opt-in (e.g. TASKLESS_ALLOW_UNVERIFIED_SCRIPTS=1), since an agent can set CI=1 as easily as it can pass the flag. CI=1 still forces a deliberate second step, which is the main goal.
Refs #403
--dangerously-run-scriptsruns a runtime rule'scheck.ts(arbitrary code) with no server verification. Today it is accepted in any context, so an agent that hits a withheld or unverified runtime rule can add the flag to get a green run and carry on. #406 tells thecheckandcirecipes not to do that, but a recipe is advice and the flag is the gate.Proposal
Accept the flag only when a human is plausibly present or the caller has declared a CI context:
process.stdin.isTTY(or stdout) is true, orCI=1/CI=trueis set.Otherwise refuse with a coded error (e.g.
UNSAFE_FLAG_REQUIRES_TTY) that says why, so an agent stops and asks the user instead of retrying. The refusal must happen before anycheck.tsis loaded.Where the flag is accepted today
taskless check(commands/check.ts, plan viarules/runtime/plan.ts)taskless test/ verify (commands/verify.ts,rules/inspect.ts)taskless demo(commands/demo.ts)Recipes that must change with it
agent/create-runtime-rule.mdtells an agent to runtest .taskless/rules/runtime/<name> --dangerously-run-scriptsas an ordinary authoring step (line ~104), andagent/verify-rule.mdoffers the flag as an alternative to a blessed signature. Under this gate an agent in a non-TTY shell withoutCIis refused at that step, which is the intent, so the recipe needs to say "ask the user to run this, or to confirm" instead.Open question
Whether
CI=1should be enough on its own, or whether CI should also need an explicit opt-in (e.g.TASKLESS_ALLOW_UNVERIFIED_SCRIPTS=1), since an agent can setCI=1as easily as it can pass the flag.CI=1still forces a deliberate second step, which is the main goal.Refs #403