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: sg and vale 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.

Most Rules Are Inert

Two of the engines produce rules that are pure data:

• sg rules (.taskless/rules/sg/) are ast-grep patterns.
• vale rules (.taskless/rules/vale/) are prose styles and their scope.

Neither executes anything. Running one never runs code and never makes a network call, so they always run, in every mode, with no account. There is no code-execution risk in either.

Note that “inert” is about execution, not about capability or trust. These rules are not a lesser version of anything. They are unexecuted, which is precisely why they need no verification. There is nothing to verify.

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. A rule file arriving in a pull request is code arriving in a pull request. Taskless treats that as a hard boundary: a runtime rule runs only when its check.ts has been verified.

The gate follows from executing code, not from what you pay for. 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 sg and vale 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.