Deploy Safety is the check that runs before your code ships. It parses your changes, blocks anything that would leak a credential, and flags config that will break in staging, all without your source code leaving the editor.
Real AST scanning
The scanner uses tree-sitter to parse your changes into a real syntax tree across JavaScript, TypeScript, TSX, Python, and Go. AST parsing is preferred because it understands code structure; regex is only a fallback when a file fails to parse. Several analysis passes run in parallel (type checks, environment-variable usage, secret detection, and more).
Secret detection is a hard block
Roughly eighteen format-anchored credential patterns (OpenAI keys, GitHub tokens, Stripe live keys, AWS access keys, Slack tokens, GitLab tokens, private-key headers, and more) are treated as hard blocks. A hard block cannot be overridden, period. A staged `.env` file is also a hard block. This is the one safety rule with no escape hatch, by design.
Overrides for non-secret warnings
Lower-severity findings (a high-entropy string that might be a secret, a localhost reference, a missing env var) can be overridden, but the override has a quality gate: you must give a specific reason of at least twenty characters, lazy phrases like "fix later" or "wip" are rejected, and every override is audit-logged.
Staging config checks
Deploy Safety extracts the environment variables your code reads (from the AST) and cross-references them against your local `.env` files, flagging variables that are used but missing or empty. That catches the class of bug where a deploy works locally and breaks in staging because a variable was never set.
Your code stays put
The entire scan runs locally in the extension. Only file paths and environment-variable names are sent to the backend for audit and reporting. Your source code is never transmitted.