Dev & Engineering terminal-tuicoding-agentrustmcpagent-skillszed-acplocal-modelssandboxed-execution

VT Code

A secure, open, universal terminal coding agent in Rust that pairs model reasoning with a sandboxed, verifiable runtime harness — from question to reviewed change without leaving the terminal.

FollowAgents review · FARS-2.1
Use with care
66/ 100 5-point scale 3.3 / 5
1 2 3 4 5 6
1Trust21 / 29 · 3.6/5

Positive evidence: CI pins actions by SHA, uses minimal permissions and persist-credentials:false, verifies rustls-only linkage, runs cargo-audit and cargo-unmaintained; README claims sandboxed shell, command policies, workspace approvals, fail-closed defenses; WebMCP tests prove pairing credentials are never persisted, guarded revert, stale-patch rejection. Deductions: the sandbox/approval implementation (e.g. SECURITY_MODEL.md) is not present in the supplied files, so these remain README assertions; cargo-deny license/dependency check is commented out; the curl|bash install script content is unseen. least_privilege and external_effects get 2, not 3. Source attribution is thorough (LICENSE, CI-synced THIRD-PARTY-NOTICES, contributor credits): 3.

2Reliability8 / 14 · 2.9/5

Clear self-contradiction: Cargo.toml declares rust-version = "1.93.0" while the CI MSRV job is named and pinned to 1.88 — both cannot hold, scoring 1. Dependency availability is supported by Cargo.lock, --locked builds, and pinned patches/workspace deps: 2. Failure messaging is supported by strict clippy anti-panic/anti-swallow lints and tests exercising stale-patch and malformed-response error paths: 2.

3Adaptability12 / 18 · 3.3/5

Targets interactive and long-running autonomous scenarios with TUI/CLI/headless entry points, 31 providers plus local inference, providers_whitelist restriction, multi-platform CI, and local-model guides; experimental status is flagged and capability boundaries are expressed via status notes and feature flags. Since the referenced doc files themselves were not provided, each criterion is 2 rather than 3.

4Convention13 / 18 · 3.6/5

Excellent information architecture: layered docs tree, complete README contents, CI-enforced link integrity: 3. License handling is exemplary: dual license declared, metadata consistent, CI-checked third-party notices: 3. Version 0.158.2 is semantically versioned and workspace-consistent, but no CHANGELOG appears in the provided files so update history is unverifiable: 1. Install notes cover cargo/brew/script channels with an API-key caution, but piping a remote script to bash ships without checksum guidance: 2. Maintenance responsibility is shown via sponsorship, contribution paths, and a security advisory process, without a governance doc: 2.

5Effectiveness7 / 13 · 2.7/5

Output usability is backed by the ThreadEvent contract, unified diffs, the review command, and regression tests: 2. Marginal value: the harness-not-wrapper positioning, open protocol stack, and 31 providers are differentiators, but the space is crowded and superiority is not evidenced by eval data: 2. Cost-benefit: cost guardrails are only mentioned in the README with no visible budget/quota implementation, scoring 1.

6Verifiability5 / 8 · 3.1/5

Major claims trace to specific doc paths, config fields, or CI jobs; README, Cargo.toml, workflows, and tests mostly corroborate each other, the MSRV mismatch being the notable exception (deducted under reliability); fact/inference separation is good with explicit experimental markers, each 2. This is a static review with no build or test execution; overall confidence is low.

Evidence confidence: Low Reviewed Sep 07, 2026 Reviewed revision 34ba18bec2a2
Before you use it
  • The recommended curl|bash install cannot be audited before execution; prefer cargo install or brew and verify checksums.
  • MSRV inconsistency: Cargo.toml requires 1.93.0 while CI checks 1.88; users on older toolchains may fail to build.
  • The sandbox and security model are mostly README assertions; the supplied files do not include the implementation. Review docs/security/SECURITY_MODEL.md and command-policy code yourself before enabling autonomous modes in production.
  • The cargo-deny (license/dependency policy) check is commented out in CI, leaving supply-chain policy coverage incomplete.
  • No CHANGELOG file; rapid 0.158.x iteration makes behavioral changes hard to assess before upgrading.
  • Publisher is unverified in the enterprise registry and treated as unknown; no score was awarded or deducted for identity.
Review evidence [1][2][3][4][5][6][7]
See the full review method →

What does this agent do, and when should you use it?

VT Code (GitHub: vinhnx/VTCode) is an open-source Rust terminal coding agent for interactive and long-running autonomous work, delivered as a responsive TUI plus headless CLI modes. It positions itself as a harness, not an LLM wrapper: the model reasons while the runtime provides tools, context, sandbox, state, evaluation, and verification. It ships 31 built-in providers — including multi-model gateways like OpenRouter, Merge Gateway, and Vercel AI Gateway — plus experimental local inference via Ollama, LM Studio, and llama.cpp. It is protocol-native, supporting MCP, Agent Skills, Agent Plugins, ACP (Zed), A2A, WebMCP, and Open Responses. Its safety model includes a sandboxed shell, command policies, workspace approvals, and fail-closed defenses against injection, path/symlink escape, and environment leakage. Licensed MIT OR Apache-2.0 per the README (Apache-2.0 on GitHub), it is in active development with some flows explicitly experimental.

After vtcode init scaffolds config and AGENTS.md in a project, you set OPENAI_API_KEY or run vtcode login for OAuth providers. Core entry points: vtcode launches the interactive TUI (ratatui/crossterm); vtcode ask answers one-shot questions; vtcode exec runs headless tasks; vtcode review reviews uncommitted changes; vtcode models list/config manages providers, optionally restricted per workspace via providers_whitelist in vtcode.toml. The runtime is built around a canonical ThreadEvent contract enabling replay, archives, checkpoints, memory views, and trajectory export, with durable session memory, task tracking, spooled output, automatic compaction, resumable handoffs, and verification before marking done. Inside the TUI, /local manages local models and /webmcp pair <origin> (or vtcode webmcp serve) pairs a browser session against a bounded workspace. Extension is via Skills, Agent Plugins, and MCP integration.

  1. Experienced developers who want question-to-reviewed-change workflows entirely in the terminal.
  2. Teams using OpenRouter or custom OpenAI-compatible gateways who need per-workspace provider restriction via providers_whitelist.
  3. Developers who cannot or prefer not to use cloud APIs and want experimental local inference with Ollama, LM Studio, or llama.cpp.
  4. Zed editor users who want to connect a coding agent through the Agent Client Protocol.
  5. Automation scenarios needing checkpoints, session resume, and verification before completion on long-running tasks.
  6. Security-conscious users who need sandboxing, command policies, and injection/escape defenses.

What are this agent's strengths and limitations?

Pros
  • 31 built-in providers plus local inference (Ollama, LM Studio, llama.cpp) keep model lock-in low.
  • Documented safety model: sandboxed shell, command policies, workspace approvals, fail-closed defenses (SECURITY_MODEL.md).
  • Protocol-native extensibility via MCP, Agent Skills, Agent Plugins, ACP (Zed), A2A, WebMCP, and Open Responses without core forks.
  • ThreadEvent runtime contract enables replay, checkpoints, and trajectory export; long tasks are observable and resumable.
Limitations
  • Actively developed; local inference and some automation flows are documented as experimental and may change between releases.
  • Users must manage their own API keys (README warns never to commit keys or put them in vtcode.toml).
  • Contributing requires Rust stable, edition 2024, ~30 layered crates; tests must use cargo nextest, never cargo test — a higher engineering bar.
  • Adoption ties you into its own config surface (vtcode.toml, AGENTS.md scaffolding); migrating to other agent frameworks means reconfiguration.

How do you install or deploy this agent?

curl -fsSL https://raw.githubusercontent.com/vinhnx/vtcode/main/scripts/install.sh | bash
# or: brew install vinhnx/tap/vtcode
# or: cargo install vtcode

How do you use this agent?

cd path/to/your/project
vtcode init                    # scaffolds config + AGENTS.md; review before committing

export OPENAI_API_KEY="sk-..." # or vtcode login for OAuth providers

vtcode                         # interactive TUI
vtcode ask "explain Rc vs Arc" # one-shot question
vtcode exec "refactor main.rs" # headless task
vtcode review                  # review uncommitted changes

How does this agent compare with similar options?

The README explicitly frames itself as a harness rather than a wrapper and documents ACP integration for Zed (docs/guides/zed-acp.md); no direct competitor is named, so no comparison is claimed.

FAQ

Which models does it support — is OpenAI required?
31 built-in providers including OpenRouter, Merge Gateway, and Vercel AI Gateway, plus custom OpenAI-compatible endpoints; experimental local inference via Ollama, LM Studio, and llama.cpp managed with /local in the TUI. Restrict per workspace with providers_whitelist in vtcode.toml.
How does it stay safe?
A sandboxed shell, command policies, workspace approvals, and fail-closed defenses against injection, path/symlink escape, and environment leakage; WebMCP serving is bounded to an allowed root.
Can autonomy be controlled?
Yes — planning, human approval, isolated worktrees, propose/verify sub-agents, and full automation, with cost guardrails, scale autonomy safely.
How stable is it?
It is in active development; local inference and some automation flows are experimental and may change between releases.

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents