snow-cli installs as the npm package snow-ai and runs a postinstall script

The repository, the npm package, and the command have three names

The repository is snow-cli. The package published to npm is snow-ai. The command you type afterwards is snow.

Installation is global:

npm install -g snow-ai

followed by

snow

package.json makes the mapping explicit. The name is snow-ai, the bin entry maps snow to bundle/cli.mjs, the description is Agentic coding in your terminal, and the keywords list includes both snow and snow cli. The repository field points at the snow-cli GitHub URL.

So a support question about snow-ai is a question about snow-cli, and a script that shells out has to call snow. Three names for one tool is a small thing that costs an hour the first time somebody searches npm for the name they saw in a repository URL.

The engines field sets the floor: node at 22 or newer, and npm at 8.3.0 or newer.

npm install -g snow-ai runs a postinstall script

The scripts block includes a postinstall entry pointing at scripts/postinstall.cjs, alongside prepublishOnly, which runs the build.

That means a global install executes code from the package immediately, before you run anything. The package is an agentic coding tool whose documented modes include executing commands directly from messages, so the install-time script runs in a process that is about to be trusted with shell access. That combination is worth a read of scripts/postinstall.cjs before the first install rather than after.

The published surface is narrow, which helps. The files array contains exactly two entries, bundle and scripts. The published package is the built bundle plus the scripts directory, nothing else.

It also means scripts is shipped to every user, so a postinstall that only builds from a development checkout is shipping source to everyone who installs the tool. Both halves are worth checking on your own machine, since the tarball is the thing that runs.

The repository carries a crates directory and three build entry points

The project is typed as TypeScript, and the top level is consistent with that: source/, build.mjs, build-ncc.mjs, build-shim.js, tsconfig.json, package.json, and package-lock.json.

There is also a crates/ directory, which is the Rust convention, and it is not in the published files list. So the repository contains a native component that the npm tarball does not, and the reader has to work out from the build scripts whether the released binary contains it.

The build pipeline shows three entry points and one chain. The build script runs scripts/clean-build.cjs, then tsc, then scripts/build-native.cjs, then node build.mjs. Separately there is a build:ts script that is just tsc and a build:bundle script that is just node build.mjs. The native step sits between compilation and bundling, which is where a Rust crate would be compiled in.

Two more directories sit at the root for the editor side: VSIX/ and JetBrains/. The documentation's installation guide covers IDE extension installation alongside system requirements, so the repository carries packaging for both a terminal tool and editor plugins, while the published npm package carries only the terminal bundle.

Tests are prettier, xo, and ava, and releases land daily

The test script is a chain of three tools:

prettier --check . && xo && ava

xo is the linter, also exposed on its own as the lint script, and prettier has a matching format script that writes instead of checking. The test target therefore fails on formatting before it runs a single assertion, and lint has no separate place in the chain because xo already does it.

The release cadence is the other thing to notice. Three recent tags are v0.8.35 on 2026-09-20, v0.8.36 on 2026-10-01, and v0.8.37 on 2026-10-02, with package.json at 0.8.37 and the last push to the repository on 2026-10-02. Two patch releases in consecutive days, a month after the previous one.

That is a project shipping often, which is good for fixes and means you should expect the version on your machine to be behind whatever is current. Pin deliberately if a particular release fixed something for you.

Three separate mechanisms govern whether the agent runs a command

An agent that writes and runs code has to answer one question repeatedly, and this tool documents that answer in more than one place.

The command injection mode guide covers executing commands directly in messages, with the syntax explained, the security mechanisms described, and use cases listed. The sensitive commands configuration is a separate document about sensitive command protection and custom command rules, so there is a place to define which commands are considered sensitive and what to do about them. Async task management adds a third: it covers background task creation and a management interface, and it lists sensitive command approval as one of its concerns, plus task to session conversion.

Then there is the SSE service mode, which describes running as a service, the API endpoints, the tool confirmation flow, permission configuration, and a YOLO mode alongside them. The presence of a YOLO mode next to a tool confirmation flow in the same document means the confirmation is a setting, not an invariant.

The dependencies explain how the agent reaches a machine: ssh2 and tough-cookie with fetch-cookie and node-fetch are there for remote and session-aware access. So the blast radius of an approval decision is whatever the session can reach.

A vulnerability hunting mode ships inside the same binary

One of the feature guides is a vulnerability hunting mode, described as professional security analysis, vulnerability detection, verification scripts, and detailed reports.

It is a documented mode of a general purpose coding agent, alongside the command panel, headless mode, MCP configuration, skills, LSP configuration, team mode, and custom StatusLine plugins. Nothing about the mode is separate from the rest of the tool: same install, same permissions, same command approval settings.

That is worth stating plainly for anyone evaluating it. A mode that produces vulnerability detection and verification reports can generate and run scripts against a target. Used against systems you own or have written authorisation to test, it is a workflow feature. Pointed at a third party, the same scripts are the problem rather than the product, and no documentation in this repository grants that permission.

Two adjacent features are worth pairing it with in your own review. The skills guide covers tool restrictions, and the async task guide covers sensitive command approval. The permission surface exists; how tightly you set it is the decision that matters.

The relay table invites stations that arrive with a test account

The README keeps a relay station table with a stated policy above it: the entries are mutual recommendation partnerships rather than commercial sponsorships, and any relay station that provides a Snow CLI usage tutorial and a test account for availability verification is welcome to join. One station is listed, named ccapi.

A test account is the phrase to notice. It means the verification standard for joining the table is a working account on the station's own infrastructure, which is a third party between you and a model provider.

This is treated as a normal configuration surface. The advanced configuration list includes a third-party relay configuration document covering a Claude Code relay, a Codex relay, and custom headers, so choosing where your traffic goes is a supported path rather than a workaround. The consequence is the ordinary one for any relay: the operator of the relay sees the requests and the responses.

The sponsor table works the same way. The Bloome entry links through a URL carrying referral and campaign parameters, and the JetBrains entry is an open source project sponsor providing free IDE licenses. Different relationships, both with the URL saying which is which, which is more disclosure than most projects make.

Node 22, a font recommendation, and a Chinese-first support channel

The practical setup notes are specific. PowerShell 7 or newer and Windows Terminal are the recommended Windows combination, installable with:

# Install using winget (built-in for Windows 10/11)
winget install Microsoft.PowerShell
winget install Microsoft.WindowsTerminal

# Or install using the Microsoft Store

A font is recommended too, JetBrains Maple Mono NF, which is a patched Nerd Font. That is a terminal rendering requirement, so it tells you the tool draws glyphs that an ordinary monospace font will not have.

Support runs through a QQ group numbered 910298558 and a Telegram channel, and the README ships in English and Simplified Chinese with a language switch at the top. The project description itself carries both an English line and a Chinese line naming Deepseek, OpenAI, Gemini, and Claude as compatible providers.

Nothing here names a Slack channel, a forum, or an issue template, so the community surface is two chat platforms and the GitHub repository itself.

Editorial conclusion

snow-cli fits someone who wants one terminal agent that speaks several model providers and wants MCP, LSP, headless, and SSE surfaces in the same tool. Four things to check before you install it globally. That the postinstall script is one you have read, because npm runs it on install and this tool is built to execute shell commands on your behalf. Which approval path you will actually be on, since command injection rules, the async task approval flow, and the SSE tool confirmation flow with its YOLO mode are three different mechanisms. Whether a third-party relay is in your path, because a relay between you and a provider sees your traffic and the documentation treats relays as a normal configuration step. And, for any security work you point it at, that the target is yours or you are authorised, since a vulnerability hunting mode ships in the same binary.

Frequently asked questions

Official sources

1. Issues
2. MayDay-wpf/snow-cli on GitHub
3. README
4. Releases