Veto

veto

93 agentic tools. 49 specialists. Every major AI CLI. Self-learning. Zero extra cost on subscriptions.

An MCP server that runs locally on your machine, plugs into Claude Code, Codex CLI, Gemini CLI, Antigravity CLI, Cursor, Windsurf, Zed, and JetBrains using your existing subscriptions — giving every AI a council of specialist agents, local LLM support, SDD agents, playwright automation, persistent cross-platform memory, a self-learning router that re-tunes its tier thresholds automatically every 20 recorded task outcomes (reviews record outcomes for you; configurable via auto_apply_learning), CI/CD gates, workspace discovery, and bidirectional IDE communication.

Billing note: "Zero cost" applies to subscription plans (Claude Max, Gemini Advanced, etc.). If you are on API/pay-per-token billing, LLM reasoning done for Veto agents (via the agentic loop or MCP Sampling) counts toward your token usage like any other turn. veto init detects API key environment variables and warns you automatically.

---

Getting Started

# 1. Install the CLI — puts the bare `veto` command on your PATH
npm i -g @jigyasudham/veto

# 2. Register Veto with every AI client you use (Claude Code, Gemini, Codex, Cursor, …)
veto init

Prefer not to install anything? Every command also works via npx:

npx -y @jigyasudham/veto@latest init

The two are independent by design. veto init writes MCP configs that launch the server with npx -y --package @jigyasudham/veto@latest veto-server — npx re-resolves @latest against the registry on every client restart, so the MCP server auto-updates itself and a global copy can never pin it to an old version. The global install only provides the CLI (veto doctor, veto sessions, the statusline, …); keep it current with npm i -g @jigyasudham/veto@latest when veto doctor says it's behind.

---

How the Agents Work

No API keys, zero extra cost. Every worker agent is a deterministic expert module at its core, with two optional layers of LLM reasoning on top — all of it delegated to the AI you're already paying for.

Default — Deterministic expert modules

Out of the box, each of the 42 worker agents runs as a hand-written expert module (plan() / analyze() in src/agents/) — not an LLM. They always run, work offline, and cost zero tokens. Their depth varies by design: analysis agents (security scanner, secrets, dependency audit, clone detector, privacy, auth, performance, compatibility, …) apply real algorithms — regex/AST detection, OWASP/CWE rules, hash-based clone matching — while planning agents (coder, debugger, tester, …) are structured expert playbooks: curated steps, checklists, and pitfalls for the task category, built to be reasoned over by the AI you already pay for rather than to reason themselves.

Path A — Agentic loop (most clients: Claude Code, Cursor, Windsurf)

Veto returns the specialist's role, rubric, and an output contract as an llm_upgrade prompt. The host AI reasons as the specialist and passes structured JSON back to complete the operation. This is the primary path — it costs nothing beyond your existing subscription and works on every client.

Path B — MCP Sampling (clients that support server.createMessage)

Where Sampling is available, the same upgrade happens server-side without the extra round-trip. Note: the July 2026 MCP spec revision deprecates Sampling protocol-wide (12-month sunset), so the agentic loop (Path A) is Veto's long-term default; Sampling remains a transparent optimization where it exists.

The 7-agent Council is LLM-first — its value is the multi-agent debate — but it too falls back to a deterministic verdict when no LLM path is available. When multiple agents run, they execute in parallel.

---

Specialist Roles

49 specialists: 42 deterministic worker agents across 6 domains + a 7-agent Council. The Council debates trade-offs before you build; the worker agents do the hands-on analysis and planning. Each is a deterministic expert module that can upgrade to LLM reasoning — see How the Agents Work. List them anytime with veto agents.

Council (7) Lead Dev · PM · Architect · UX · Devil's Advocate · Legal · Security

Development (12) Coder · Code Reviewer · Tester · Debugger · Refactor · Database · API · Frontend · Backend · DevOps · Performance · Migration

Security (6) Security Scanner · Auth Agent · Data Privacy · Secrets Agent · Dependency Audit · Penetration Tester

Memory (5) Context Manager · Decision Logger · Project Mapper · Pattern Learner · Knowledge Base

Research (7) Researcher · Tech Advisor · Cost Analyzer · Competitor Analyzer · Risk Assessor · Estimator · Ethics & Bias

Quality (5) Code Quality · Documentation · Accessibility · Compatibility · Error Handling

Workflow (7) Task Planner · Task Coordinator · File Manager · Git Agent · Search Agent · Reporter · Automation

---

MCP Tools (93)

Category	Tools
Session	veto_status · veto_session_save · veto_session_restore · veto_sessions_list · veto_autosave_status · veto_session_replay
Router	veto_route_task · veto_rate_status
Council	veto_council_debate · veto_benchmark · veto_adr
Agents	veto_agent_plan · veto_execute_parallel · veto_explain · veto_compose_agents · veto_delegate
Review	veto_code_review · veto_security_scan · veto_secrets_scan · veto_diff_review · veto_full_review · veto_pr_review
Pipelines	veto_ci_gate · veto_pre_commit · veto_new_feature · veto_workflow · veto_task_parse
Advanced	veto_local_llm · veto_semantic_search · veto_sdd_agent · veto_playwright · veto_notify_ide
Quality	veto_clone_detector · veto_lint_rules · veto_api_contract · veto_a11y_advisor · veto_type_coverage · veto_test_gaps
Advisors	veto_dep_advisor · veto_dep_verify · veto_query_advisor · veto_bundle_advisor · veto_dead_code · veto_hitl_checkpoint · veto_drift_check
Watching	veto_watch · veto_watch_poll · veto_watch_stop
Memory	veto_memory_store · veto_memory_search · veto_memory_delete · veto_decisions · veto_project_map_update · veto_project_map_get · veto_pattern_store · veto_patterns_list · veto_memory_export · veto_memory_import
Learning	veto_record_outcome · veto_learning_stats · veto_learning_apply
Handoff	veto_handoff · veto_continue · veto_platform_setup
Observability	veto_usage_status · veto_audit_log · veto_health · veto_metrics · veto_snapshot
Discover	veto_discover · veto_summarize · veto_git_blame · veto_changelog · veto_onboard · veto_debt_register
DevTools	veto_docs_fetch · veto_context_status · veto_openapi_gen · veto_flag_auditor · veto_env_setup · veto_commit_message · veto_pr_description · veto_pr_post · veto_prompt_optimizer · veto_sre_advisor · veto_diagram · veto_rca · veto_doc_gen · veto_postmortem · veto_release_notes · veto_translate · veto_merge_conflict
Plugins	veto_plugins

Compact Mode — 93 tools without the context tax

93 tool schemas cost a client ~20K context tokens before the user types a word. Compact mode advertises a surface that is 5–6× smaller: seven core tools (veto_status, veto_session_save, veto_session_restore, veto_route_task, veto_council_debate, veto_memory_search, veto_record_outcome) plus two meta-tools — veto_find_tools searches the full catalog by keyword and returns matching schemas on demand; veto_call invokes any catalog tool by name. Every tool remains directly callable in both modes; compact only changes what is advertised up front.

Enable it with VETO_COMPACT=1 in your MCP server config env, or "compact_tools": true in ~/.veto/config.json:

{
  "mcpServers": {
    "veto": {
      "command": "npx",
      "args": ["-y", "--package", "@jigyasudham/veto@latest", "veto-server"],
      "env": { "VETO_COMPACT": "1" }
    }
  }
}

Dependency-Hallucination Guard

LLMs propose plausible-but-nonexistent package names, and adversaries register those names on public registries (slopsquatting) — a supply-chain attack class with no pre-install check in most AI workflows. veto_dep_verify checks every proposed package against the live registry before you install:

veto_dep_verify { packages: ["axios", "axois", "left-padd"], ecosystem: "npm" }
→ axios      verified    (14 years old, 40M downloads/month)
→ axois      HIGH_RISK   (1 edit from "axios" — possible typosquat)
→ left-padd  NOT_FOUND   (likely hallucinated — do NOT retry the install later:
                          nonexistent AI-suggested names are prime slopsquat targets)

Signals per package: registry existence, age, monthly downloads, version history, deprecation, and typo-distance from popular packages. Supports npm, PyPI, and crates.io. Network failures return unverifiable — never silently safe.

Decision-Drift Enforcement

AI assistants forget architectural decisions and re-litigate them sessions later — the most common complaint about long-running AI projects. Veto's memory doesn't just store decisions; it enforces them. Record a decision once as a machine-checkable constraint:

veto_decisions {
  action: "add",
  rule: "We use Postgres — no Mongo",
  why: "Decided 2026-05: relational data, team expertise",
  forbidden_patterns: ["mongoose", "mongodb"],
  severity: "block"
}

From then on, veto_diff_review and veto_ci_gate automatically fail any diff whose added lines match a forbidden pattern — when an AI quietly adds mongoose to the imports three sessions later, the review fails with the rule and the rationale attached. Patterns are case-insensitive regexes (with substring fallback), optionally scoped to a file glob (src/**/*.ts), per-project or global, severity block or warn. Manage with action: list / check / disable / enable.

You don't have to remember to do this. When a council verdict (the LLM-backed one) or an ADR settles something, its result carries a one-time constraint_invitation: your AI asks you once whether it should become a rule, and passes your answer back as add or decline with the invitation_id. It never asks twice about the same verdict. action: list shows how many invitations were offered, accepted and declined; that count stays on your machine.

A rule can't stall your reviews. add refuses a pattern that could hang the check: one over 200 characters, or a repeated group that itself repeats, like (a+)+. Every check is also time-boxed, so a slow rule turns into a warning instead of blocking veto_ci_gate.

Compounding-Error Circuit Breaker

Agents fail silently in loops — retrying the same broken call, re-hitting the same error, thrashing between two tools — and burn a whole session before anyone notices. veto_drift_check scans the recent tool-call trace for that pattern mid-flight and trips a breaker before the spiral compounds:

veto_drift_check
→ DRIFT DETECTED
  • 4 consecutive failed calls (veto_diff_review)
  • same error repeated 3× ("no diff provided")
  • tool veto_route_task called 6× in a row
→ remediation (debugger agent): stop retrying; the diff is empty —
  point at a project_dir with uncommitted changes or pass `diff` explicitly.

It looks for three drift signals — consecutive failures, duplicate error messages, and single-tool repetition — and when any trips, it runs the debugger agent over the trace for a concrete recovery step instead of letting the loop continue. Call it as a periodic checkpoint in long agentic runs.

Which tool do I use?

Several tools overlap by design (different granularity or entry point). Quick guide:

Reviewing code

You have…	Use	Note
A snippet or single file in hand	veto_code_review	not veto_diff_review, which reads a git diff
Uncommitted/changed files (git diff)	veto_diff_review	code + security + secrets scans in parallel
To gate a commit (hard-block on secrets)	veto_pre_commit	tuned for commit-time
To gate CI (exit code + pass/warn/fail)	veto_ci_gate	for GitHub Actions / GitLab CI
A deeper pre-merge/pre-ship pass (+ quality)	veto_full_review	richer than veto_diff_review
A GitHub PR by number/URL	veto_pr_review	fetches the diff, returns postable comments

Remembering things

Want to…	Use
Save/recall a solution, decision, or reference	veto_memory_store / veto_memory_search
Track a recurring code convention	veto_pattern_store / veto_patterns_list
Navigate the codebase without scanning the filesystem	veto_project_map_get (refresh via veto_project_map_update)

Running multi-step work

Want to…	Use
Run several agents at once on one task	veto_execute_parallel
Run a sequential pipeline with pass/fail gates	veto_workflow
Turn a PRD / plain English into a task DAG	veto_task_parse (feeds veto_workflow)
Plan a new feature end-to-end (council → plan → tasks)	veto_new_feature

Sessions

Want to…	Use
Resume work with full saved context	veto_session_restore (or veto_continue for the latest)
See the event / tool-call timeline of a session	veto_session_replay
Move work to another AI tool	veto_handoff → veto_continue

MCP Resources

URI	What it returns
veto://sessions	All saved sessions across platforms
veto://project-map?dir=<path>	Stored project structure map
veto://memory?q=<query>	Knowledge base search results
veto://patterns	Learned coding patterns

MCP Prompts

Prompt	What it does
code-review	Full code review — paste code, get scored findings
security-audit	OWASP Top 10 scan with CWE references
deploy-checklist	Council reviews your deployment plan before you ship
explain-file	Expert explanation of any file, auto-routed by type

---

CLI Commands

These work standalone in any terminal — no AI client needed. The bare veto command comes from the global install (npm i -g @jigyasudham/veto, see Getting Started); without it, prefix any command with npx -y @jigyasudham/veto@latest.

veto init                        # Register Veto with every AI app found + scan project
veto doctor                      # Per app: does it list Veto, does Veto start, has the app started it?
veto doctor --quick              # Same, without launching the server to test it
veto doctor --fix                # Also move aside old Veto guides left in Codex/Gemini files
veto status                      # Version, DB path, session/memory/outcome counts
veto version                     # Alias for veto status
veto sessions [words]            # Newest 20 saved sessions, and how many exist ([auto] = auto-save)
veto sessions --all | --limit N  # All of them, or N; add --json for machine output
veto sessions --clean            # Remove auto-saves older than 7 days
veto continue <id> --as <client> # Restore a session from a terminal (8-character id prefix is enough) —
                                 #   the same code as veto_continue, for an app that did not load Veto
veto memory [query]              # Search knowledge base (blank = all entries)
veto patterns [prefix]           # List learned agent/routing patterns
veto tools [filter]              # List all 93 MCP tools (--json for machine output)
veto agents [filter]             # List all 49 specialists — workers + council (--json)
veto routing [status|log|reset]  # Inspect the opt-in routing feedback loop
veto transcripts <sub>           # Opt-in transcript capture (off by default) —
                                 #   enable|status|sources|list|show|purge|disable
veto lessons <sub>               # Opt-in note sharing between your AIs (off by default) —
                                 #   on|status|list|why|forget|flows|off|exclude|include|alias|recheck
veto statusline <sub>            # Veto line under the Claude Code prompt, or beside
                                 #   Codex/Gemini — install|status|print|watch|uninstall
veto api <command>               # JSON for editor extensions — version|snapshot|recall search|
                                 #   recall expand|diagnostics (see "For editor extensions" below)
veto hook install                # Install pre-commit secrets scan hook
veto hook remove                 # Remove the veto pre-commit hook
veto check                       # Scan staged changes for secrets (used by hook)
veto help                        # Commands + MCP tools reference
veto help --troubleshoot         # Full troubleshooting guide

veto doctor

veto doctor

  Veto Doctor — system health check
  ─────────────────────────────────────────────────────
  ✓ Node.js v22.13.0 (this terminal)
  ✓ ~/.veto exists
  ✓ Database ~/.veto/veto.db
    17 sessions · 12 memories · 3 patterns

  AI apps — registration · launch test · last start
  ─────────────────────────────────────────────────────
  ✓ Claude Code — connected
      source: claude mcp list
      launch test: answered in 1.2 s — Veto 3.7.0, 93 tools
      last started by claude-code 2.1.0 3 h ago — Veto 3.7.0, Node v22.13.0
  ✗ Antigravity — Veto is only in ~/.gemini/antigravity-cli/mcp_config.json, a file Antigravity no longer reads
      fix: veto init   (then fully restart the app)
  · Gemini CLI — not installed

  Fallback guidance — what an AI is told when Veto did not load
  ─────────────────────────────────────────────────────
  ✓ ~/.claude/skills/veto/SKILL.md

  ⚠  1 issue found. Each has its fix above.

Every ✓ says what it rests on. Registration is what the app's own mcp list reports (or the file the app reads, when its CLI is not on PATH). The launch test runs the exact configured command and completes the MCP handshake, which catches npx failing to reach the registry and a server that exits on start. Last started comes from the server itself: each time an app starts Veto, it records which app, which Node, and whether SQLite loaded in that app's runtime (~/.veto/host-starts.json). That is the only check that sees a GUI app launching Veto with a different Node than your terminal. veto doctor exits with status 1 when it finds an issue, so scripts can rely on it.

When an AI's app did not load Veto, Veto's veto skill (written by veto init into Claude Code, Codex and Antigravity/Gemini skill folders) tells it to say so and use veto continue / veto sessions / veto doctor instead of reading Veto's database by hand.

Versions of veto init before this release wrote Veto's guide over ~/.gemini/GEMINI.md (Gemini's own memory file) and into ~/.codex/AGENTS.override.md, which Codex reads instead of your ~/.codex/AGENTS.md. Current versions never write either file. veto doctor reports any copy left behind, and veto doctor --fix (or veto init) renames a copy to *.veto-backup — only when the file is exactly a guide Veto shipped. A file with anything else in it, such as memories Gemini saved below the guide, is reported and never touched. What an old init overwrote cannot be recovered.

For editor extensions: veto api

An extension that shows Veto's state reads it through veto api, not by opening Veto's databases. Every response is one JSON envelope on stdout (contract, command, backend_version, state, and message / next_action whenever state is not ok). Its shape is versioned apart from Veto. Within contract 1, fields are only added, so ignore fields you do not know.

Command	Request	Returns
version	—	contract version, commands, the CLI's path, whether SQLite loads
snapshot	{ project, db? }	capture state, archive counts for the project, lesson sharing and counts, the trial's progress. Read-only, and returns counts rather than paths
recall search	{ project, query, limit?, source?, db? }	masked hits from that project's archived chats, and the matching chats' segments
recall expand	{ project, event_id } or { project, archive_id, segment_index }	masked text of one turn or segment, only if it belongs to that project
diagnostics	{ checks?: ["host_cli", "probe"], db? }	veto doctor's per-app checks. The slow ones run only when named

Send the request as JSON on stdin, and start the CLI with an argument array and no shell: execFile(process.execPath, [cliPath, 'api', 'recall', 'search', '--stdin']), where cliPath comes from veto api version. On Windows, veto is a .cmd shim that only a shell can start, and passing a search query through a shell turns it into a command line. A project is always required, and a db other than the one Veto uses is refused with db_mismatch rather than answered from the wrong database. Archives kept after capture is turned off can still be searched, and each response says what state capture is in. veto transcripts purge is what deletes them. The JSON Schemas and example responses ship in the package under contracts/api-v1/.

veto statusline

In Claude Code, veto statusline install adds a Veto line under the prompt: the latest council verdict, router confidence, live context and rate-limit use, and memory size. While note sharing is on, it also shows how many notes Veto holds (notes 178); with sharing off, that count is left out rather than shown as zero.

Codex and Gemini cannot run a custom status line — each only shows its own built-in items (Codex: openai/codex#20244). So there, the same line runs in a small split pane beside the AI and follows its session in the current folder:

veto statusline watch                    # follows whichever AI is working in this folder
veto statusline watch --client=codex     # or pin one: claude | codex | gemini
veto statusline install --client=codex   # prints the split-pane setup for your terminal; writes nothing

For Codex it reads context and rate-limit use from Codex's own session file; Gemini records no usage figures, so its line shows the live session without gauges. veto statusline print --client=codex prints one line, for a tmux status bar or a script.

---

Council Debate

Two-phase flow — works on Claude Code, Gemini CLI, Antigravity CLI, and Codex CLI with no API keys:

# Phase 1 — call with task, get instant deterministic result + LLM upgrade prompt
veto_council_debate {
  task: "migrate auth from sessions to JWTs",
  project_dir: "/your/project",
  strictness: "standard"
}
→ {
    llm_backed: false,
    final_verdict: "YELLOW",
    votes: { lead_dev: {...}, architect: {...}, security: {...}, ... },
    llm_upgrade: {
      available: true,
      instruction: "Read debate_prompt, reason as all 7 agents, call again with agent_responses",
      debate_prompt: "You are running a Veto Council debate. Analyze the task as each specialist..."
    }
  }

# Phase 2 — reason as all 7 agents, pass responses back → get LLM-backed verdict
veto_council_debate {
  task: "migrate auth from sessions to JWTs",
  agent_responses: {
    lead_dev:  { verdict: "warn",    reason: "Stateless JWTs complicate logout — need blocklist", concerns: ["Refresh token rotation must be atomic"], recommendation: "Use short-lived access tokens (15m) + httpOnly refresh tokens" },
    pm:        { verdict: "approve", reason: "JWT migration unblocks mobile clients", concerns: [], recommendation: "Ship behind a feature flag, roll back if logout issues" },
    architect: { verdict: "approve", reason: "Good fit for stateless microservice boundary", concerns: ["Clock skew can break expiry across services"], recommendation: "Add NTP sync check; use relative expiry not absolute timestamps" },
    ux:        { verdict: "approve", reason: "No user-visible change if migration is seamless", concerns: [], recommendation: "Silent migration — no logout required for existing sessions" },
    devil:     { verdict: "warn",    reason: "What if the refresh token store goes down at 2AM?", concerns: ["Redis outage = all users logged out"], recommendation: "Fallback to session auth if Redis is down; use short rotation window" },
    legal:     { verdict: "approve", reason: "JWTs are industry standard, no new compliance risk", concerns: [], recommendation: "Document token storage in privacy policy" },
    security:  { verdict: "warn",    reason: "Refresh token rotation must be atomic — TOCTOU risk", concerns: ["localStorage storage of access token is XSS-vulnerable"], recommendation: "Store access token in memory only; refresh token in httpOnly Secure SameSite=Strict cookie" }
  }
}
→ {
    llm_backed: true,
    final_verdict: "YELLOW",
    warnings: ["Refresh token rotation must be atomic...", "What if the refresh token store goes down..."],
    recommended: "Proceed with JWT. Use httpOnly cookies for refresh tokens, memory-only for access tokens..."
  }

Council strictness

veto_council_debate { task: "...", strictness: "fast" }     # 3 agents, instant
veto_council_debate { task: "...", strictness: "standard" } # 7 agents, default
veto_council_debate { task: "...", strictness: "strict" }   # 7 + devil rebuttal

---

Session Tagging + Search

veto_session_save {
  auto_summarize: true,
  tags: ["auth", "jwt", "middleware"]
}

veto_sessions_list { query: "auth" }
→ sessions matching "auth" in summary, context, tags, or project_dir

Token usage is manually reported — pass token_count to veto_status or veto_session_save and Veto stores it per platform per day. veto_rate_status shows what you've reported; nothing is counted automatically.

---

Workspace Discovery

veto_discover { "project_dir": "/your/project" }
→ {
    git:        { branch: "main", commit: "a3f2b1", dirty_files: [], recent_commits: [...] },
    ecosystems: { node: "my-app v2.1.0" },
    tech_stack: ["TypeScript", "React", "Prisma"],
    key_files:  ["tsconfig.json", "prisma/schema.prisma", ".env.example"],
    total_files: 142
  }

---

Diff Review

veto_diff_review { project_dir: "/your/project" }
→ {
    verdict: "warn",
    files_changed: 4,
    code_review: { score: 78, critical: 0, high: 2, findings: [...] },
    security:    { score: 91, critical: 0, high: 0, findings: [...] },
    secrets:     { findings: [] },
    summary: "⚠️  WARN — 4 file(s) changed..."
  }

---

Sequential Pipelines

veto_workflow {
  steps: [
    { id: "code",     agent: "coder",           task: "implement auth middleware", gate: 70 },
    { id: "review",   agent: "reviewer",         task: "review the implementation", gate: 75 },
    { id: "security", agent: "security-scanner", task: "scan for vulnerabilities",  gate: 80 },
    { id: "test",     agent: "tester",           task: "write test cases" }
  ],
  project_dir: "/your/project"
}
→ { verdict: "passed", steps_passed: 4, steps_failed: 0, results: [...] }

---

Self-Learning Router

Every agent tool auto-records a quality signal when it completes. After any working session, veto_learning_stats shows live data and veto_learning_apply adjusts tier thresholds automatically after ~20 calls.

The loop also feeds itself implicitly: veto_learning_stats mines the tool-call trace for signals nobody recorded manually — an agent-backed tool that returned an error, or the same analysis tool re-run within minutes in one session (which usually means the first answer didn't satisfy) — and records them as low-quality outcomes automatically.

veto_route_task { task: "debug auth issue", file_ext: ".ts" }
→ { ..., recommended_agent: "debugger" }   # ← predicted from history

---

Plugin System

// ~/.veto/agents/my-agent.js
export function plan(task, context) {
  return {
    agent: 'my-agent', task, tier: 2,
    approach: 'Your custom approach...',
    steps: ['Step 1', 'Step 2'],
    checklist: ['[ ] Check 1'],
    pitfalls: ['Pitfall 1'],
    patterns: ['Pattern 1'],
    duration_estimate: '1-2 hours',
  };
}

---

Cross-Platform Handoff

Claude at 90%  →  veto_handoff { summary, context }
Open Gemini    →  veto_continue { resuming_as: "gemini" }
Full context restored. Continue exactly where you stopped.

Platform switching is manual — Veto surfaces which platform has budget remaining via veto_rate_status, you decide when to switch.

Platform	Support
Claude Code	✅ Native MCP
Gemini CLI	✅ MCP support
Antigravity CLI	✅ MCP support
Codex CLI	✅ MCP support
Cursor	✅ MCP support
Windsurf	✅ MCP support
Zed	✅ MCP support (context_servers)

---

Session Transcript Capture (opt-in)

veto_session_save writes a ~1k-token summary. That is enough to resume, but not enough to answer "three weeks ago, what exactly did we conclude, and when?" Transcript capture keeps the detail a summary throws away and makes it searchable — with no API keys, no per-query cost, and nothing leaving your machine. It is a metadata table-of-contents plus a portable BM25 index built on core SQLite only — no FTS5, so it works on every supported Node — fused with local semantic search, and your AI as the reranker.

⚠️ Read this before you enable it

Veto copies your AI client's own conversation memory. On save, Veto archives a byte-for-byte copy of the host CLI's transcript file — every message you sent, every reply, and all tool activity — into its own local store.

• The copy is independent. The original file is never modified, but Veto's copy outlives it. Clearing your AI client's history, or the client rotating its own logs, will not remove the archive. Only veto transcripts purge or the retention window does.
• It inherits whatever was in the session. Secrets, customer data, third parties' information — if you pasted it, it is in the archive. Detected secrets are masked everywhere an AI can read them, but the raw archive on disk is private data. Treat it like your shell history.
• Local only. Nothing is uploaded or shared. The archive directory deliberately avoids cloud-synced folders, and a sync path is flagged if one is detected.
• Off until you say so. Capture is disabled by default. veto transcripts enable prints this disclosure in full and records versioned consent; if the disclosure materially changes, you are re-prompted.

veto transcripts enable          # Opt in — prints what/where/retention, records consent
veto transcripts status          # State, archive dir, retention, disk usage
veto transcripts sources         # Per-CLI: where sessions live + what Veto can see
veto transcripts list            # Archived sessions
veto transcripts show <id>       # One session's table-of-contents + facts (any AI's session id)
veto transcripts purge <id>      # Delete an archive (also --project=<dir> | --all; --source=codex to narrow)
veto transcripts disable         # Stop capturing (existing archives are kept)

Works in Claude Code, Codex CLI, Gemini CLI and Antigravity CLI

All four are captured and recalled through the same pipeline, each with its own format adapter, and Veto works out which one it is running in by itself — the MCP handshake names the host, so nothing depends on the AI reporting it correctly. Veto finds each host's session files on disk at save time (Claude Code's statusline, when installed, also reports its session live). A project folder matches however a host spells it — Gemini records d:\veto for the folder a save calls D:\Veto. Antigravity's conversations are matched to a project through Antigravity's own conversation index, which Veto opens read-only. veto transcripts sources shows exactly what it can see for each, and when a save archives nothing, its response says why.

Each adapter was written against real transcripts rather than docs, which is how two format traps got handled: Codex records every message on two parallel streams, and Gemini's chat log appends a fresh copy of a message each time it grows. Both would otherwise put several copies of the same message into the index.

Recall runs through veto_session_replay as a two-call loop — search, then expand:

{ query: "npm E404 publish" }   →  table-of-contents + top hits with snippets
{ expand: { event_id: 412 } }   →  the exact lines, masked, with a turn + timestamp citation

Past sessions, used without asking

Recall only helps if an AI thinks to reach for it, and mostly it did not. So the tools where history changes the answer bring it along themselves, from every archived chat — whichever AI it happened in:

• veto_continue / veto_session_restore list the chats behind the saved session (for example a Codex chat and two Claude Code chats) and what was asked last in each.
• veto_memory_search returns matching excerpts from past chats beside stored memory.
• Every prompt Veto hands a model — agent tools and the council — carries up to three relevant excerpts.

An excerpt is attached only when it is conversation (not a tool payload) and shares at least two words with the question; nothing is attached while capture is off. Excerpts are labelled as historical data, not instructions, and the deterministic analyzers never receive them, so an old excerpt cannot become a finding.

Semantic recall — finding what you can't quite remember

Keyword search fails on the question you actually have. You remember what was decided, not the words it was written in — so "why did the upload fail" never finds the note that says "the credentials had expired".

Veto searches meaning as well as words. Each captured event is split into overlapping windows and embedded locally; a query is embedded the same way, and the two rankings — keywords and meaning — are fused so neither can bury the other. An exact identifier like E404 still ranks first, and a question sharing no vocabulary with its answer still finds it.

This runs entirely on your machine. No API key, no per-query cost, no text leaving the disk, and it works offline. What buys that is a 7 MB embedding table installed as a normal dependency:

• It is downloaded once per machine by npm's shared cache, not per project.
• It ships with Veto whether or not you enable transcript capture. That is the honest cost of the design: pinning an immutable package means the bytes can never change under a released version, and it removes the runtime download, checksum and mirror machinery that a fetch-on-demand model would need.
• It is loaded lazily, at the first semantic query — never at startup. If it is missing or damaged, search silently falls back to keywords only and Veto keeps working.

The table is potion-base-8M by Minish Lab (MIT), distilled from baai/bge-base-en-v1.5 and repacked to int8. It is a static lookup table, not a neural network: there is no model running at query time, which is why a search costs milliseconds. The inference code is Veto's own.

Notes Shared Between Your AIs (opt-in, trial)

Claude, Codex and Gemini each keep notes in their own memory: Claude's per-project memory folders, ~/.codex/AGENTS.md, ~/.gemini/GEMINI.md. Each AI learns something, and the others never hear of it; the same lesson gets learned twice in two projects. Veto reads those notes and can share them where they help: across your projects, and between your AIs.

⚠️ What turning it on means

• Across your projects: a note about you or this computer, written while you worked on one project, can be shared into your others.
• Between AIs: a note Claude wrote can reach Codex and Gemini, and the other way round. A note given to an AI goes to that AI's company as part of your conversation, like anything else you send it.
• Read-only. Veto never changes or deletes an AI's memory files. It keeps a copy of each note in its own local database, with email addresses, your home folder and anything that looks like a password or key removed first. Veto itself uploads nothing.
• Off until you say so, and only you can say so. veto lessons on shows this disclosure and asks you to type yes in a terminal of your own. When an AI runs the command, it is refused, so no AI can switch sharing on for you. No upgrade ever turns it on, and if what sharing does materially changes, you are asked again.
• A trial for now. Veto gives none of the notes to any AI yet. Turning sharing on starts nothing else: a separate trial, which you start yourself with veto lessons trial, can record which notes Veto would have given your Codex sessions, and it asks you first; see The trial. Before Veto starts giving notes to your AIs, it will ask you again.

Most notes never leave their project. A note stays home if it is about that project, or if it contains a command, a web address, a credential or an instruction to fetch, send or run something; notes about secrets or personal details never leave their project at all. Only a note about you (Claude's user and feedback notes, a CLI's global instructions) or about this computer (its shell, console or network) may travel. A shared note arrives marked as information from another AI session, never as an instruction.

veto lessons on                  # Read the disclosure; type yes to accept (your own terminal only)
veto lessons trial               # The trial: its lists and progress; starts it when you type yes (your own terminal only)
veto lessons trial ignore [dir]  # Before it starts: record sessions in this project as skipped (also: use [dir], clear)
veto lessons                     # Status: notes found, how many may travel, anything switched off, and the trial so far
veto lessons list                # Every note Veto has read, by project (--shared, --held, --scope=, --source=, --json)
veto lessons why <id>            # One note: who wrote it, when, why it stays or travels, where it may go
veto lessons flows               # Where each AI's notes may go, per project
veto lessons forget <id>         # Stop one note for good, with its copies in your other checkouts
veto lessons exclude [dir]       # Keep a project out entirely: nothing leaves it, nothing enters it
veto lessons include [dir]       # Undo exclude: the project's notes are read again
veto lessons alias               # Memory on a drive that isn't plugged in: suggests the command that links it
veto lessons recheck <ai>        # Read an AI's memory again after Veto stopped because its format changed
veto lessons off                 # Turn sharing off and delete everything Veto copied, trial records included

Picked up when you save

With sharing on, every veto_session_save also re-reads each AI's memory and records what changed, so a note an AI wrote today is picked up without you running anything. A file that has not changed costs one check of its size and date, which adds about 20 ms to a save. The pass is capped at 150 ms a save, anything it does not reach waits for the next save, and it can never cause a save to fail. Turning sharing on reads everything once, up front, and veto lessons commands always check every file. To stop only the save-time pass, set lessons.harvest_on_save to false in ~/.veto/config.json.

The trial

Before Veto gives any AI a note, it has to show that the notes it would give are real and useful. The trial is how: it records what Veto would have given, and gives nothing. It is opt-in on its own: turning sharing on does not start it.

• Choosing projects (optional): before you start, veto lessons trial ignore <dir> records that project's sessions as skipped, and veto lessons trial use <dir> makes only the projects you list count. veto lessons trial clear empties both lists. A project is matched by its git history, so every checkout of it counts the same; a folder without git is matched by its path. Anyone, your AI included, can set the lists, and they are kept only in your ~/.veto/config.json.

• Starting: veto lessons trial shows what the trial records and both lists, and starts when you type yes in a terminal of your own. An AI cannot start it for you. Once it runs, the lists cannot change.

• When it stops: after 10 weeks, or once 12 notes have been chosen, whichever comes first.

• What counts: Codex sessions in a project that has notes to choose from. A session's first request is matched against the notes Veto held when that session began, so a note that arrived or changed later does not count. A subagent is not counted twice. A session in an ignored project is recorded as skipped: its message is not used, and no note is chosen for it. Claude Code sessions are not part of this trial: Claude already loads its own project's notes, which leaves almost nothing to add.

• What you do: use Codex for real work in a project that has notes, and start each session with a proper description of the task, since that is what notes are matched against.

• What you see: veto lessons and veto lessons trial show the trial as it goes. It also warns if several sessions in a row yield no request at all, which most likely means Codex changed its format rather than that no note fitted.

  Trial:        day 18 of 70 · 4 of 12 notes chosen
                23 Codex sessions counted · 3 with notes chosen · 20 with none that fitted · 9 skipped
  

• Your record stays yours: it stays on your machine, and Veto collects nothing from it. veto lessons off deletes it. If transcript capture is on, finished trial sessions that count are archived too, including Codex sessions you never saved with Veto, so the evidence behind each choice is kept.

• What decides delivery: the trial on the Veto author's own machine, under rules written and sealed before it recorded anything. When it ends, an independent AI judge scores each chosen note against what its session went on to do, once. If the notes are not clearly real and useful, delivery does not ship. If they are, delivery can be designed, and Veto will ask every user for consent again before any note reaches an AI.

Upgrading from 3.6.0–3.8.0

Sharing stays on, and you are not asked again. Those versions started a trial automatically when you accepted sharing; 3.9.0 stops it on upgrade and records nothing more unless you start the new trial yourself with veto lessons trial. What the old trial recorded is kept, shown as "Trial 1: ended" in veto lessons, and veto lessons off still deletes it.

Upgrading from 3.5.0

3.6.0 asks for your consent again, because 3.5.0's text said Veto worked out nothing about which notes it would give, and the trial does exactly that. Until you run veto lessons on in your own terminal and accept, sharing is paused: nothing is read, harvest-on-save stops, and the trial does not start. The notes Veto already holds are kept.

---

Release Notes

3.9.0

• The notes trial is now something you start yourself. Accepting sharing used to start a trial automatically, on every computer that turned sharing on, although nothing from those trials ever leaves the computer. Now veto lessons trial shows what the trial records and starts it only when you type yes in your own terminal; an AI cannot start it for you. Before starting, veto lessons trial ignore <dir> and use <dir> choose which projects count. A session in an ignored project is recorded as skipped and nothing is chosen for it. The trial stops after 10 weeks or 12 chosen notes. See The trial.
• If you turned sharing on in 3.6.0–3.8.0: sharing stays on, with no new question, because the consent text only lost its promise of an automatic trial. That trial stops on upgrade. Its records are kept, shown as "Trial 1: ended", and veto lessons off still deletes them.
• Bug fix: veto doctor said Codex sessions would be examined on the next save after the trial had already finished. A finished trial examines nothing, and doctor no longer says it will. It now also warns when trial records exist but no trial is running, which means Veto's config was damaged or edited by hand.
• veto api snapshot reports the trial's trial_id, stop_on, notes_chosen, notes_target and skipped count. These fields are added to contract v1, nothing is removed, and the lists of folders are never returned.

3.8.0

• New: veto api, JSON for editor extensions. The VS Code extension could show Veto's database but not whether transcript capture was on, what the notes trial had found, or anything from past chats, so it had to say "unknown". veto api snapshot reports capture, lessons and trial state for a project. It reads without changing anything: it uses read-only connections, runs no migration, harvest or trial pass, and returns counts rather than your folders. veto api recall search and recall expand give the same search as veto_session_replay, with the scope an editor needs checked by Veto. A project is required, an event or segment from another project is refused, text is masked, and raw source is never returned. veto api diagnostics returns veto doctor's per-app checks as data. Requests go in as JSON on stdin, so search text never passes through a shell. The contract is versioned apart from Veto, and its JSON Schemas and examples ship under contracts/api-v1/. See For editor extensions.
• Bug fix: veto continue and veto sessions failed inside Codex's sandbox. When Veto's tools did not load in Codex, the veto skill correctly sent Codex to veto continue, but Codex's default sandbox lets a command write only inside the workspace, and Veto wrote to its database every time it opened it, even to read. Both commands stopped with attempt to write a readonly database. They now fall back to reading the database without writing. veto continue still returns the whole saved session and says what it could not do: record who resumed it, and add past-session excerpts. Tested in Codex's own sandbox (codex sandbox), where 3.7.1 fails and 3.8.0 restores the session.
• Bug fix: Antigravity chats were not captured. With transcript capture on, a save made in Antigravity archived nothing, because Veto could not read Antigravity's chats. It now reads them from ~/.gemini/antigravity-cli/brain/<conversation>/, finds each conversation's project in Antigravity's own conversation index (opened read-only), and skips conversations started by another conversation and those from the Antigravity editor. Antigravity chats are searched and expanded like the others, veto transcripts sources lists them, and veto doctor checks that their capture keeps up. This is covered by the capture consent you already gave, which never named particular apps.

3.7.1

• Bug fix: Veto did not know it was running in Antigravity. Antigravity names itself antigravity-client when it starts Veto, which Veto did not recognise. A session saved there was labelled claude unless the model said otherwise, a session resumed there was not recorded as resumed by Antigravity, and a model that described itself as gemini made transcript capture archive a Gemini CLI chat, which is another app's conversation. Antigravity is now recognised as its own app. Saves and resumes are labelled antigravity, capture skips it (Veto cannot read Antigravity's chats), and antigravity is an accepted value wherever a tool asks which app you are in. veto_health reports the app too.
• Bug fix: Antigravity never saw the veto skill. 3.7.0 wrote it to ~/.gemini/skills, a folder Antigravity does not read, so with Veto's tools missing it still got no guidance. It now goes to ~/.gemini/config/skills, where Antigravity lists it. Tested with Veto switched off: Antigravity read the skill, said Veto's tools were not loaded, and ran veto continue instead of searching the disk. Run veto init after updating to install it there.

3.7.0

• Bug fix: Antigravity never loaded Veto. Antigravity reads its MCP servers from ~/.gemini/config/mcp_config.json; veto init wrote ~/.gemini/antigravity-cli/mcp_config.json, which it does not read, and veto doctor checked that same file and printed ✓. Init now registers through each app's own CLI where it has one (claude mcp add, codex mcp add, agy mcp add), so the app decides where its config lives. Without that CLI it writes only the file the app reads. It handles the empty file Antigravity creates, which the old writer skipped as "unreadable", and never rewrites a file with comments (Zed's) or broken JSON.
• veto doctor checks that each app really runs Veto, not that a file mentions it. It reads what the app itself reports (including a disabled entry), launches the configured command to see it answer, and shows when each app last started Veto, with which Node and whether SQLite worked there. It also checks that transcript capture and the lessons trial are still keeping up, and exits 1 on any issue. Its Node check was also wrong: it accepted 22.5–22.12, where persistence does not work.
• New: veto continue <id> --as <client>, and veto sessions --all | --limit N | [words]. An AI whose app did not load Veto can restore a session from a terminal through the same code as veto_continue, without reading Veto's database or importing its files, which is what one did before. veto_continue and veto continue accept the 8-character id prefix that listings show. veto sessions says how many sessions exist, not just the newest 20.
• New: the veto skill. Written by veto init into Claude Code, Codex and Antigravity/Gemini skill folders. It is the one instruction an AI still sees when Veto did not load: say so, use the CLI, never read the database. It never replaces a veto skill you wrote yourself.
• Bug fix: tools returned filler as results. Without an LLM step, generators filled their output with unrelated text: veto_diagram returned "mermaid": "Documentation looks complete.", and veto_pr_description, veto_release_notes, veto_prompt_optimizer, veto_rca, veto_postmortem and veto_onboard did the same. Each now returns only what it computed (commits, routes, counts, error-budget maths, the code at a stack trace) and marks the rest generation: "needs_llm", with the prompt to finish it. Generated output is checked before it is returned: veto_doc_gen refuses a file that lost code, veto_diagram refuses text that isn't Mermaid, veto_openapi_gen refuses a non-OpenAPI document.
• Bug fix: tools dropped their inputs. veto_secrets_scan never received its text. veto_translate never received its text or languages. veto_semantic_search never received its query, and veto_explain, veto_merge_conflict and veto_a11y_advisor never read their file. Every input now reaches the agent, files are read (a missing one is an error), and analysis tools run Veto's own scanner first and return its findings even without an LLM.
• Bug fix: scanners that could never find anything. veto_dead_code and veto_flag_auditor passed GNU grep options to git grep and always reported nothing. Both now scan for real: exports no other file uses, commented-out code, and feature flags with their locations. The security scanner missed the most common SQL injection ("… id = '" + req.params.id) and now reports the line. veto_clone_detector reported code as a clone of itself and split one copy into several findings. veto_openapi_gen only looked at files named route*/api*.
• Bug fix: wrong numbers. veto_dep_advisor asked OSV about 4.0.0 for a ^4.19.2 dependency. It now uses the installed or locked version and returns each advisory's summary, severity and fixed version. veto_debt_register gave every item "complexity, 2 hours", and several tools returned hard-coded blanks or zeros as results.
• Bug fix: keyword verdicts presented as reviews. With no LLM available, council votes come from keyword rules. Such a verdict is now labelled as preliminary, is no longer saved as the project's latest verdict or stored in memory as a decision, and can no longer block veto_new_feature. veto_benchmark no longer picks a "winner" from it. A council answer missing most of its members no longer reports itself as fully LLM-backed.
• Other fixes. veto_project_map_get crashed after a map was saved as an object. veto_git_blame ignored project_dir. veto_pr_post sent review comments GitHub rejects (they now go in the review body). veto_env_setup could replace an existing .env.example with a placeholder. veto_workflow ran malformed steps. veto_notify_ide said "sent" for actions MCP cannot perform. veto_code_review now stores the editor diagnostics its description promised. On Windows, project lookups now match whatever case each app spells the folder in, and veto memory export --format=markdown finds your project's entries again.
• Bug fix: the Claude Code secrets hook never ran. The hook veto init installed read a file path from an environment variable Claude Code does not set, so it passed every file. It is replaced in place by one that reads Claude Code's hook input and reports findings back to Claude. Two hook files Claude Code never runs are removed, but only when they are exactly what Veto wrote.
• Windows: Veto's own background commands no longer flash console windows, and a failed update check retries hourly instead of on every start.

3.6.0

• The shared-notes trial now measures whether the notes would help. Before Veto gives any AI a note, it has to show that the notes it would give are real and useful. For 8 weeks or 20 Codex sessions, whichever comes first, Veto reads the first message of each Codex session in your projects from Codex's own session files, works out which notes it would have given that session, and records only that choice. It never keeps your message, and it still gives no note to any AI. Sessions are found from Codex's own files rather than from Veto's connection, because the Codex VS Code extension runs many conversations in one process and would otherwise be missed. Only the notes Veto held when a session began count, and subagents are not counted twice. veto lessons shows how the trial is going, and warns if sessions stop yielding a request, which would mean Codex changed its format. If transcript capture is on, finished trial sessions are archived so each choice can be checked later. Your record stays on your machine, and nothing judges it; whether delivery ships is decided by the trial on the author's own machine, under rules sealed before it began.
• Sharing pauses until you accept again. Consent moves to version 3, because the version-2 text said Veto worked out nothing about which notes it would give, and the trial makes that untrue. Anyone who turned sharing on in 3.5.0 sees it paused, with nothing read, until they run veto lessons on in their own terminal and accept the new text. Nothing already harvested is deleted. Before any note is actually given to an AI, Veto will ask again.
• Catching up after an upgrade is much faster. When every memory file needs reading again, which happens whenever Veto changes how it reads them, harvest-on-save used to take 16 to 25 saves to catch up, each using its full time budget. Almost all of that went on running git again for every project folder on every save. Veto now remembers which project each folder belongs to, and catching up takes 3 to 5 saves. veto lessons commands still work each folder out afresh.
• Removed: the unused shadow log. 3.4.0 and 3.5.0 created a table for the trial that nothing ever wrote to. Its design would have stored each session's prompt, which the trial must never do. It is dropped on upgrade while empty, and replaced by the trial's own table, which stores only the choice.

---

View the full README on GitHub