VTCode ships a Rust agent whose exec mode needs two switches

The quick install pipes a script into bash and brings two search tools with it

The quick start opens with a single line:

curl -fsSL https://raw.githubusercontent.com/vinhnx/VTCode/main/scripts/install.sh | bash

Two other routes are named beside it. A Homebrew tap has to be trusted before it can be used, with `brew trust vinhnx/tap` followed by `brew install vinhnx/tap/vtcode`, and there is `cargo install vtcode` for anyone with a Rust toolchain. The installation guide is pointed at for prerequisites, other methods, and the installer script you can review before running, which is the mitigation the project offers for a pipe-to-bash. What makes that line worth reading rather than skipping is that the script does more than fetch a binary: it also sets up `ripgrep` and `ast-grep` on macOS and Linux. So one curl brings down a text search tool and a structural search tool alongside the agent, and both become things the agent expects to find. An `sgconfig.yml` at the repository root is the configuration surface for the second one.

Windows is crossed rather than built, and the page says it may lag

There is one platform note on the front page and it is a hedge: Windows artifacts are best-effort and may lag behind macOS and Linux. The tree gives the reason without stating it. `Cross.toml` is a cross-compilation manifest and `Dockerfile.build` sits beside it, so the Windows artefact is produced by crossing the toolchain rather than by running a Windows builder, which is the usual reason a port trails. Two other build inputs confirm that the packaging is deliberate rather than incidental: a `homebrew/` directory backs the tap the quick start tells you to trust, and the release manifest `release.toml` sits next to the changelog configuration `cliff.toml`. The repository also carries a `fuzz/` directory, a `benches/` directory, a `rule-tests/` directory, and a `patches/` directory, so this is a build system with a project inside it rather than a single binary dropped into a folder.

Three patch releases in two days and a Rust floor stated to three digits

The three most recent releases are 0.171.5 dated 2026-10-02, 0.171.4 earlier on the same day, and 0.171.3 dated 2026-10-01. Two releases on one date and three across two days is a fast cadence for a version number sitting in the third decimal place, and it means a pinned version is a short-lived thing. The manifest agrees with the newest tag, since its own version is 0.171.5. Build requirements are stated exactly rather than loosely: edition 2024, and a `rust-version` of 1.98.1, which is a specific patch-level floor rather than a major version. A `rust-toolchain.toml` at the root is a second place the same toolchain gets pinned. Licensing is a choice of two rather than one: the manifest declares MIT OR Apache-2.0, while the repository record names Apache-2.0 alone, so the manifest is the wider grant and the metadata is the narrower one.

A Rust workspace with a package.json containing exactly one dependency

The root of this Rust project includes a `package.json`, and its entire contents are one dependency: `@openai/codex-security` at 0.1.1. There is no name field, no version, no scripts block, and no engines field. So exactly one npm package is pulled into a project whose build runs through Cargo from one end to the other, and the file sits next to `Cargo.lock`, `Cargo.toml`, `build.rs`, a `crates/` directory, an `apps/` directory, and a `utils/` directory. Having a JavaScript manifest in a Rust repository is ordinary when a workflow step or a scanner needs a tool that ships on npm, and this one names a package with `codex-security` in it, which reads as an advisory-scanning dependency rather than a build input. Worth naming before anyone assumes the frontend build lives in that file.

exec needs a configuration switch and a workspace trust decision

Headless mode splits into three verbs with three different reaches:

vtcode ask "explain Rc vs Arc"    # one-shot answer, no session, no tools
vtcode exec "refactor main.rs"    # headless task with the full tool loop
vtcode review                     # agent review of uncommitted changes

`ask` does not touch tools or keep a session, `review` looks only at uncommitted changes, and `exec` is the one that does real work. It is gated twice. Autonomous execution has to be enabled in `[automation.full_auto]`, and the workspace has to carry `full_auto` trust. A terminal prompts you for that trust, while a non-TTY run fails outright unless the environment sets `VTCODE_TRUST_WORKSPACE=full-auto`. Full-auto is not unlimited: the tool allow-list, the explicit denies, and the execution policy all still apply on top of it. The page also says something worth keeping about results, pointing at an eval framework for repeatable environment-checked work and stating that a completion message alone is not verification.

A key can live in three places and none of them is the config file

Credentials are described with more care than most projects manage. The example environment file says it is optional and that the shell is the preferred route, giving an export in a shell profile as the example. Keys pasted into the setup wizard go into the OS keyring rather than into that file, on the stated grounds of not duplicating a secret for every workspace. And the runtime infers the variable name from the provider setting rather than asking: openai maps to `OPENAI_API_KEY`, anthropic to `ANTHROPIC_API_KEY`, gemini to `GEMINI_API_KEY`, deepseek to `DEEPSEEK_API_KEY`, evolink to `EVOLINK_API_KEY`, and litellm to `LITELLM_API_KEY`, with an OpenRouter key and a Google-format alternative listed separately plus base URL overrides for two of them. Discovery happens on first launch, so an already exported key is found without being pasted again. Against all of that the caution is absolute: never commit keys, and never put them in `vtcode.toml`.

Sessions fork, schedules reuse the exec runtime, and the TUI can pair with a browser

Three mechanisms sit outside the interactive loop and each reuses something already there. Sessions are resumable rather than transient: `vtcode continue` picks up the most recent interactive session, `vtcode exec resume --last "continue the refactor"` continues the last headless run with a follow-up prompt, `vtcode continue --session-id <id>` forks an earlier session rather than only replaying it, and `vtcode trajectory` prints the execution log. Scheduled tasks are described as durable prompt jobs on the same exec runtime, so anything the gate applies to `exec` applies to a cron entry too:

# Weekly dependency audit (Mondays 09:00)
vtcode schedule create --name "weekly-dep-audit" \
  --cron "0 9 * * 1" \
  --prompt "Check for outdated dependencies and report known vulnerabilities"

The third mechanism crosses out of the terminal entirely. WebMCP pairs the TUI with an authenticated browser editor through a single command typed inside the interface, `/webmcp pair <origin>`, and the hosted app at the project's chatgpt.site address uses that same workspace-scoped bridge with a mirror on the author's GitHub pages. The page is explicit that extensions are optional, since MCP servers, Agent Skills, and plugins are all framed as enable-them-only-when-you-need-them.

The published crate re-includes one config document out of an excluded tree

The manifest's exclude list is long: `target/`, `.github/`, the whole `docs` tree, `scripts/`, `screenshots/`, `logs/`, `prompts/`, `dist/`, `npm/`, and `resources/`. Inside the documentation exclusion there is one negation, which re-includes `docs/config/CONFIG_FIELD_REFERENCE.md`. So the crate published to the registry carries the configuration field reference while the rest of the documentation stays out, and that single file is the one the author treats as required to use the tool. Two further manifest choices say something about what this is. The documentation field points at docs.rs, so the crate is published as a library as well as a binary, and a default-run entry pins the executable name. The workspace dependency list lines up with the features described on the page: a diff library with inline and unicode support for the turn diffs view, a schema crate for generating the toml configuration, a keyring crate for the secret subcommand, and a terminal library alongside a fork of a terminal emulator for the interface.

Editorial conclusion

VTCode is worth a look if you want a coding agent where the trust decision is explicit rather than implied, because the headless path refuses to run unattended without you saying so twice. Read three things before you install. The quickest install is a curl piped into bash, and the same command also brings down ripgrep and ast-grep, so read the script before you run it or use the Homebrew or Cargo route instead. Credentials have three possible homes and the project is clear about which is which: the shell is preferred, the wizard writes to the OS keyring rather than to a file, and the example environment file is optional, with a flat prohibition on putting a key in vtcode.toml or in a commit. And Windows artifacts are described as best-effort and possibly behind the Unix builds, which the cross-compilation manifest at the root explains. If you are on Windows and need a feature from the current release, check the build date before you start.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes