This article follows the official documentation. We haven’t tested this tool for a hands-on review.
When a coding agent changes a project, it can introduce vulnerable dependencies or insecure code. Snyk CLI lets the agent run commands in a terminal to scan a project and return findings in JSON, a structured format that software can read. A finding identifies a security issue, but it does not show by itself that an attacker can exploit the project or that a fix is safe to apply.
Snyk CLI offers several types of scans. snyk test checks dependencies, while snyk code test scans source code and snyk iac test checks infrastructure configuration. An agent can run the relevant scan after editing and report the results before a person reviews the change. The commands below show a dependency scan, not a fix. This article does not verify that Snyk CLI is installed or that the commands work in your environment.
Install and authenticate
Install Snyk CLI using a supported method from the installation guide. For an npm-based setup, the documented package command is:
npm install snyk -g
The same guide covers Homebrew and standalone binaries, among other methods. Then authenticate:
snyk auth
The auth command opens a browser window where you log in to your Snyk account. Since version 1.1293, the browser login uses OAuth, which gives the CLI short-lived access that refreshes automatically. In CI, Snyk documents the SNYK_TOKEN environment variable instead. Complete authentication outside the agent prompt, and keep account tokens out of prompts and source files. Snyk CLI needs network access to its service to retrieve vulnerability information. Authentication and account access affect which Snyk features and results are available.
Run a dependency scan
From the repository root, run snyk test. The command reads supported dependency manifests, which declare a project’s dependencies, and lockfiles, which record the versions selected for them. It checks them against Snyk’s vulnerability data. Add --json when the agent needs structured output to parse or summarize:
cd /path/to/repository
snyk test --json > snyk-results.json
/path/to/repository is a placeholder for the project directory. The command writes JSON to snyk-results.json in the current directory; that redirection creates a local file, so choose a destination outside the repository if you do not want it included in a commit. The CLI command and option reference documents scan commands and output options, including SARIF output with --sarif.
The exit code tells the agent how the scan ended. snyk test returns 0 when it finds no vulnerabilities and 1 when it finds some. It returns 2 when the scan fails and 3 when it finds no supported project. An agent should read exit code 1 as a result to report and not as a broken command.
Before scanning, read Snyk’s code execution warning. To collect dependency data, the CLI may run the project’s package manager, for example npm or pip. Only scan code you trust.
The JSON lists findings for the agent to review. The result depends on the project’s supported manifests and the vulnerability data available to the authenticated account; it is not a complete review of the source code. A dependency scan does not set up ongoing monitoring in Snyk. snyk monitor is a separate command that creates a project in your Snyk account and sends a snapshot for ongoing monitoring, so an agent should not run it unless that service-side change is intended.
Snyk findings can include recommended upgrades or patches, along with the paths through which dependencies bring in a vulnerable package. To see all vulnerable paths, add --show-vulnerable-paths=all. Snyk documents these recommendations in its CLI vulnerability-fixing guidance. The scan itself is a check; remediation changes should be reviewed separately before the agent applies them.
A concise prompt for a shell-capable coding agent could be:
Run
snyk test --jsonfrom the repository root. Summarize the vulnerabilities and affected dependency paths. Do not change manifests, lockfiles, or source files. Report scan errors separately from findings.
Choose the scan that matches the change
Use snyk test when the agent edits dependency declarations or lockfiles. Use snyk code test when it changes application source and you want a scan that analyzes code for security risks, a practice called static application security testing. Use snyk iac test for files that describe infrastructure settings. Snyk also documents container scans through snyk container test; each command targets a different part of the project, so one scan does not stand in for the others.
For Serverless infrastructure, Snyk’s documentation says to generate the files used for deployment, called deployment artifacts, before testing the files. If you add --report to snyk iac test, the CLI also uploads the results to the Snyk web interface. Leave that flag out when the agent should only check the files. The Serverless file instructions describe both steps.
Snyk CLI lets an agent check dependencies or code from a terminal. Review the findings before deciding whether to merge the change. Start with the scan that matches the files the agent changed, and keep any fix or upload step separate from the read-only check.