Security

Taskless runs rules against your code, and some rules run code of their own. This page explains how that stays safe and how your data stays yours.

The short version: static rules never execute anything, and runtime rules only execute when they’ve been verified. Nothing runs untrusted code behind your back, and nothing leaves your machine unless you deliberately ask the Taskless service to generate a rule.

Static Rules Are Inert

Static rules (.taskless/rules/) are ast-grep patterns. They’re data, so running them never executes anything and never makes a network call. They always run, in every mode, with no account. There is no code-execution risk in a static rule.

Runtime Rules Execute Code, So They’re Verified

A runtime rule runs a check.ts. That’s arbitrary code, so running an unverified one means running untrusted code on your machine. Taskless treats that as a hard boundary: a runtime rule runs only when its check.ts has been verified. What “verified” means depends on your state:

• Logged in: each runtime rule’s check.ts is reconciled against the Taskless service. Only rules the service has blessed to run actually execute. The rest are withheld and reported as advisory.
• Logged out, --anonymous, no GitHub remote, or the service is unavailable: runtime rules are skipped and reported, never run. Your static rules still run normally.

Either way, skipped or withheld runtime rules are surfaced to you (on stderr, and in the skipped[] array under --json) but never change the exit code. A clean check stays clean; only real error-severity findings fail it.

Running Runtime Rules Unverified

There is exactly one way to run runtime rules without verification:

npx @taskless/cli check --dangerously-run-scripts

This runs every runtime rule’s check.ts, trusting the signatures already on disk, with no network call. The name is a warning: it executes code that hasn’t been reconciled against the service. Reach for it deliberately.

CI Is the Enforcement Point

On a normal developer machine, runtime rules are skipped unless you opt into --dangerously-run-scripts. That’s intentional: the place runtime rules are meant to be enforced is CI.

An authenticated CI job (with a TASKLESS_TOKEN secret) reconciles every runtime rule against the Taskless service and runs exactly the server-blessed set. The rules that gate your pull requests are always the verified ones, regardless of what any individual developer runs locally. See Continuous Integration for how to wire the token.

Your Data Stays Local-First

Taskless is built to keep your code on your machine by default:

• Static rules and --anonymous flows never send code off your machine. Authoring a local ast-grep rule, and running check, are entirely on-device.
• detect is offline. Scanning your repo for linters, languages, and rule styles makes no network call.
• The only path that sends code to the Taskless service is remote rule generation. It requires you to be logged in and consumes a generation, so it never happens silently. See Authoring Rules for when that path is taken.