Skip to main content
Everything Vendo adds to a repo is enumerable, so removal is too. There is no CLI verb for it: removal is deleting files.

​
Removal checklist

Work through this in the app directory you ran vendo init in. Everything listed is Vendo-owned unless marked yours.

​
1. The server surface

The mount line is app.use("/api/vendo", mountVendo()) on Express, or the handleVendoRequest wiring in your runtime’s entry.

​
2. The client mount (yours)

Remove the <VendoProvider> wrap, and <VendoOverlay /> or any other Vendo surface inside it, from your layout. That is app/layout.tsx, pages/_app.tsx, or the "use client" wrapper file you wrote to hold the component registry, which can be deleted whole.

​
3. .vendo/

Delete the directory. It holds only Vendo state: the extracted contract, the files you may have edited, capture output, AI-pass output, knowledge config, and data/.
.vendo/data/ is the local store: threads, generated apps, grants, and run history live there. Deleting it deletes them. A deployment that ran with a Cloud key kept its real state server-side, so its local data/ may be nearly empty (the Cloud side).

​
4. package.json

Remove the predev and prebuild sync hooks (vendo sync --no-ai, vendo sync --strict --no-ai). If init prepended them to a script you already had, delete just the Vendo segment. Uninstall @vendoai/vendo, the vendoai alias if present, and a direct @vendoai/ui if you added one for chrome imports. Init’s provider step also installed ai and one @ai-sdk/* provider. Remove them only if nothing else in your app imports them. Init may have bumped zod. Leave that alone: it is a version floor, not a Vendo dependency.

​
5. Environment

​
6. The long tail

Only present when the matching feature was used. ~/.vendo/ is user-level state, not project state: the CLI telemetry id, a stored Cloud session, and any pending login claim. Delete it only if you are leaving Vendo entirely.

​
The Cloud side

Deleting the key line locally does not revoke it. Revoke it in the console, or from the CLI:
What to know about hosted data:
  • Removing VENDO_API_KEY changes which store composes. Store selection is explicit store, then Cloud key, then local, so the next boot composes the local store (Persistence). Nothing migrates and there is no export command.
  • Hosted data outlives the key. Store rows, published config surfaces, pin baselines, and captured host components remain server-side after revocation.
  • Targeted deletion is programmatic. eraseStore(store, { files }) cascades per-subject and per-app; project- and account-level deletion is a console operation.
  • vendo cloud logout deletes only the local session file at ~/.vendo/cloud-session.json.

​
Start over instead

Removal is rarely what a broken install needs. In order of increasing reset: vendo init --force never touches source files. The route, the composition, and vendo-actions.ts are yours once created, so a broken one is deleted by hand and recreated by the next plain vendo init. A plain re-run prints “Already wired” and still re-runs extraction, the theme reconcile, and the AI-pass offer. Deleted scaffolds come back; edited files are never overwritten. Day to day the predev and prebuild hooks already run vendo sync, so re-init is for restoring scaffolds or reviewing queued loosenings, not for keeping tools current.