Skip to content

Full Automation

Jump to bottom
Vinh Nguyen edited this page Aug 5, 2026 · 1 revision

Full Automation

--full-auto lets VT Code run non-interactively on explicitly allow-listed tools. It is an execution and permission layer on top of the active primary agent — not a primary agent of its own. Use it only when you fully trust the workspace configuration.

--full-auto is intentionally separate from normal session permissions:

  • Normal sessions use primary agents plus granular permission rules.
  • Agent specs use permissions.default plus allow, ask, auto, and deny rule buckets.
  • --full-auto uses the explicit [automation.full_auto] allow-list as a hard gate. Tools outside the list are denied; promptable outcomes inside the list go through automatic permission review instead of asking.

Activation Checklist

  1. Update vtcode.toml — enable the feature, configure the allow-list, keep require_profile_ack = true.
  2. Create the acknowledgement profile at automation.full_auto.profile_path documenting acceptable behavior, escalation procedures, and workspace-specific hazards.
  3. Review tool policies — denied tools remain blocked; allow-listed promptable actions use automatic review.
  4. Launch — run vtcode --full-auto.

Configuration

[automation.full_auto]
enabled = true
require_profile_ack = true
profile_path = "automation/full_auto_profile.toml"
allowed_tools = [
    "exec_command",
    "write_stdin",
    "apply_patch",
    "code_search",
]
max_turns = 100
  • Include "*" only when the workspace is fully isolated.
  • If the acknowledgement profile is missing while required, the CLI aborts before launching.

Runtime Behavior

  • VT Code displays the active allow-list at session start.
  • Non allow-listed tools are rejected before execution and the attempts are logged.
  • Explicit denies and policy blocks are honored before full-auto review.

Propose/Verify Sub-agents

When verify_mutations = true, every proposed change is re-checked by a fresh read-only verifier sub-agent that re-reads the affected files and approves or rejects before the change is committed. The verifier runs with no shared context from the proposer, preventing confirmation bias.

[automation.full_auto]
enabled = true
verify_mutations = true

Default false because it roughly doubles token cost on mutating calls.

Orchestrated Harness

For longer unattended builds, prefer the planner/evaluator harness over a single uninterrupted loop:

[agent.harness]
orchestration_mode = "plan_build_evaluate"
max_revision_rounds = 2

vtcode exec --full-auto then writes working artifacts under .vtcode/tasks/:

  • current_spec.md — high-level execution spec
  • current_contract.md — observable done criteria
  • current_task.md — tracker state
  • current_evaluation.md — evaluator output

Each revision round: Planner expands the task → Build executes it → Evaluator judges the candidate → on rejection a Replanner rewrites the spec/contract/tracker from feedback → Build runs again. The run writes a blocked-handoff artifact when max_revision_rounds is exhausted.

Regression Testing

The vtcode-eval crate builds regression eval suites that verify the agent still handles previously-passing tasks after model or harness changes:

vtcode exec eval --suite my-suite.json --output report.md

Suites contain tasks with prompts, setup/verify commands, and a category (capability or regression). The runner computes pass@k and pass^k metrics and outputs a markdown report.

Profile File Recommendations

Include in the profile file: operator name and timestamp approving unattended execution, workspace-specific limitations (directories that must not be modified), contact/escalation details, and rollback procedures. Keep it under version control for an audit trail.

Related

Clone this wiki locally