v1.8.2 — Username Preferences (Professional/Casual)

Stores 6 preferred usernames in keychain — 3 professional, 3 casual — each with primary/secondary/tertiary priority.

When signing up for a new service, the agent:

1. Detects context (professional for GitHub/Vercel/AWS, casual for everything else)
2. Tries primary username → secondary → tertiary
3. Only appends a short number if all three are taken
4. Never generates random usernames like rishi-2160504210

Asked once on first signup, stored forever. Works cross-platform via keychain.sh.

v1.8.1 — Auto-start Chrome CDP

The agent now starts Chrome automatically when the browser is needed but not running. Also auto-restarts Chrome on context errors. Users never have to manually run chrome-debug.sh — the agent handles it.

v1.8.0 — Audit Dashboard, Snapshot/Rollback, Session Persistence

Autopilot v1.8.0 — Audit Dashboard, Snapshot/Rollback, Session Persistence

Three features that make autonomous execution safer, more transparent, and crash-resilient.

Audit Dashboard (audit.sh)

View the execution log from the terminal with color-coded output:

audit.sh                     # Latest session
audit.sh all                 # All sessions
audit.sh search supabase     # Search logs
audit.sh accounts            # Account activity (signups, logins, tokens)
audit.sh failures            # Failed actions only
audit.sh summary             # One-line-per-session overview

Colors: green = done, red = FAILED, yellow = ACCOUNT CREATED, blue = LOGGED IN, cyan = TOKEN STORED. Auto-detects project root.

Snapshot & Rollback (snapshot.sh)

Before executing any plan, Autopilot automatically snapshots the current state using git stash. If something goes wrong, roll back instantly:

snapshot.sh list                # List all autopilot snapshots
snapshot.sh rollback            # Rollback to latest snapshot
snapshot.sh rollback pre-deploy # Rollback to a specific one
snapshot.sh diff                # Show what changed since snapshot

Snapshots are automatic during complex tasks (Flow B). The agent creates one before executing and mentions rollback in the completion report.

Session Persistence (session.sh)

Work survives rate limits and crashes. Autopilot saves progress after each step:

session.sh status    # Check if a saved session exists
session.sh resume    # Show saved state for the agent to pick up
session.sh clear     # Remove saved session

On startup (Flow B), the agent checks for a saved session and offers to resume from where it left off. Session data includes: task, plan, completed steps, current step, services used, and notes.

Updated Execution Flow

Flow B is now: Plan > Snapshot > Check Session > Execute All

1. Check for saved session → offer to resume
2. Present plan → wait for "proceed"
3. Create snapshot (automatic)
4. Save session → update after each step
5. Execute all steps without pausing
6. Report results + mention rollback availability
7. Clear session

v1.7.1 — README Visual Redesign

Visual overhaul of the README for better GitHub presentation. Badges, collapsible sections, two-column layouts, consistent tables, and cleaner formatting. No functional changes.

v1.7.0 — Persistent Browser (Never Dies)

Autopilot v1.7.0 — Persistent Browser (Never Dies)

The #1 pain point — the browser dying mid-session — is solved. The browser now runs independently of Claude Code and survives session restarts.

How it works

Chrome runs as a persistent background process with Chrome DevTools Protocol (CDP) on port 9222. The Playwright MCP connects to it instead of launching its own browser.

Chrome (persistent, background)  <-- CDP -->  Playwright MCP  <-->  Claude Code
      |                                              |
  Always alive                                Dies with session
  Login sessions persist                      Reconnects on start

When your Claude Code session ends, the browser stays alive. When you start a new session, the MCP reconnects to the same Chrome. Login sessions, cookies, and tabs persist.

Three layers of resilience

Layer 1 — Persistent Chrome (new)

• chrome-debug.sh start launches Chrome with CDP in the background
• Survives terminal close, Claude Code restarts, and session timeouts
• Login sessions persist in ~/MCPs/autopilot/browser-profile/
• Installer auto-starts it during installation

Layer 2 — Auto-retry on context errors (new)

• If a page/context closes, the agent tries browser_close + retry once
• Recovers from tab-level crashes without user intervention
• Only falls back to CLI after retry fails

Layer 3 — Smart browser avoidance (new)

• Agent checks if browser is actually needed before using it
• Skips browser for: encrypted messaging apps, QR code flows, native apps, CLI-available operations
• Fewer browser uses = fewer chances for errors

New script: chrome-debug.sh

~/MCPs/autopilot/bin/chrome-debug.sh start    # Launch persistent Chrome
~/MCPs/autopilot/bin/chrome-debug.sh stop     # Stop it
~/MCPs/autopilot/bin/chrome-debug.sh status   # Check if running
~/MCPs/autopilot/bin/chrome-debug.sh restart  # Stop + start

After system reboot

The persistent Chrome needs to be started once after a reboot:

~/MCPs/autopilot/bin/chrome-debug.sh start

The installer does this automatically during initial setup.

v1.6.1 — /autopilot Slash Command

Autopilot v1.6.1 — /autopilot Slash Command

Use Autopilot from any Claude Code session without starting a dedicated agent.

What's new

Slash command: Type /autopilot <task> inside any Claude Code session:

/autopilot deploy this to Vercel
/autopilot set up Supabase with auth tables
/autopilot get me a Cloudflare R2 bucket

Autopilot activates for that one task — plans, executes, logs, reports — then you're back to normal coding. No separate terminal, no mode switching.

Two ways to use Autopilot

Method	When to use
/autopilot <task>	Quick tasks mid-coding: deploy, get API keys, install services
claude --agent autopilot	Full sessions: multi-service setup, project bootstrapping

Both share the same guardian, keychain, execution log, and service registries.

Installation

The installer now automatically installs the slash command to ~/.claude/commands/autopilot.md. Existing users can update by re-running ./install.sh or manually copying commands/autopilot.md to ~/.claude/commands/.

The uninstaller also removes the slash command on cleanup.

v1.6.0 — Security Hardening and Critical Fixes

Autopilot v1.6.0 — Security Hardening & Critical Fixes

Major security audit and fixes. The guardian is significantly stronger, critical bugs are fixed, and the repo is cleaned up for open source.

Guardian Hardening

Fail closed — The guardian now blocks ALL commands if jq is missing or JSON parsing fails. Previously, a missing jq meant every command passed through unblocked. A safety-critical script should never fail open.

Anti-obfuscation — New Category 0 blocks attempts to bypass the guardian:

• Encoded commands piped to shell interpreters
• Subshell execution (bash -c, sh -c, eval)
• Interpreter evasion (python -c os.system(), node -e exec(), ruby -e system())

Fixed: DELETE without WHERE — The rule that catches DELETE FROM table; without a WHERE clause was broken (piped grep wrong, never fired). Now works correctly. DELETE FROM ... WHERE ... is allowed; DELETE FROM ...; is blocked.

Fixed: --force-with-lease — git push --force-with-lease was incorrectly blocked by the force-push rule. It's now allowed (it's the safer alternative).

Fixed: Custom rules delimiter — The | delimiter conflicted with regex alternation. Guardian now supports ::: as the primary delimiter with | as legacy fallback, parsing the pattern correctly even if it contains pipe characters.

Test suite: 55 tests (up from 45) — all passing. New tests cover obfuscation bypass, DELETE without WHERE, force-with-lease, and proper non-Bash tool handling.

Critical Fixes

Uninstaller safety — The uninstaller now removes Bash from the auto-approve list when removing the guardian. Previously, uninstalling left all Bash commands auto-approved with zero protection.

Installer cleanup — Added trap for temp directory cleanup on failure. Previously, a failed install leaked temp directories.

Repo Cleanup

• Removed personal MCP entries from trusted-mcps.yaml (local paths)
• Removed personal MCPs from agent allowedTools (shadcn-ui, magicui, etc.)
• Removed project-specific RenderKit section from agent definition
• Clean slate for any user to install without seeing someone else's config

v1.5.0 — Cross-Platform Support (macOS, Linux, Windows)

Autopilot v1.5.0 — Cross-Platform Support

Autopilot now runs on macOS, Linux, and Windows. Same interface, same security model, three platforms.

Credential Store (keychain.sh)

The unified keychain.sh wrapper now auto-detects the OS and uses the native encrypted credential store:

Platform	Backend	How credentials are stored
macOS	macOS Keychain (security command)	Encrypted by Keychain Services
Linux	GNOME Keyring / libsecret (secret-tool)	Encrypted by libsecret
Windows	Windows Credential Manager (cmdkey + PowerShell)	Encrypted by DPAPI
WSL	Auto-detects: uses secret-tool if installed, otherwise cmdkey.exe	Depends on chosen backend

Same commands work everywhere:

keychain.sh get vercel api-token
keychain.sh set vercel api-token
keychain.sh has vercel api-token
keychain.sh list

Installer (install.sh)

• Auto-detects platform (macOS / Linux / Windows / WSL)
• Uses the right package manager: brew (macOS), apt/dnf/pacman (Linux), choco/winget/scoop (Windows)
• Installs credential store prerequisites automatically (libsecret-tools on Linux)
• No longer blocks non-macOS platforms

CLI Installer (setup-clis.sh)

• Tries npm first (works everywhere) for tools like Vercel, Wrangler, Firebase
• Falls back to platform-specific package managers for tools like gh, jq, aws
• Shows platform in --check output

What's the same across platforms

• Guardian hook (shell script — works in bash everywhere)
• Agent definition (markdown — platform-agnostic)
• Service registries, decision framework, execution log
• Browser automation via Playwright MCP

Prerequisites by platform

Platform	Credential Store	Package Manager	Shell
macOS	Built-in	Homebrew	bash/zsh
Linux	sudo apt install libsecret-tools	apt/dnf/pacman/brew	bash
Windows	Built-in	choco/winget/scoop	Git Bash
WSL	sudo apt install libsecret-tools OR Windows cmdkey	apt	bash

v1.4.0 — Primary Credentials and Account Tracking

Autopilot v1.4.0 — Primary Credentials & Account Tracking

Two changes that make Autopilot even more hands-off.

Primary Credentials

Set your email and password once — stored in macOS Keychain encryption. Autopilot uses these as the default for signing up and logging into any new service it encounters.

Before: Every new service required you to provide email + password.
After: You provide them once. Autopilot uses them everywhere.

Credential acquisition priority:

1. Service-specific token in Keychain (instant, no browser needed)
2. Service-specific login in Keychain (for services with different accounts)
3. Persistent browser session (already logged in from last time)
4. Primary credentials (sign up or log in automatically)
5. 2FA prompt (only remaining stop point)

Account Activity Tracking in Execution Log

The project-local execution log (.autopilot/log.md) now tracks account activity with special markers:

• ACCOUNT CREATED — agent signed up for a new service
• LOGGED IN — agent logged into an existing account
• TOKEN STORED — API token acquired and saved to Keychain

This gives you a clear record of which services have accounts and where the agent authenticated — without exposing any credential values.

| # | Time | Action | Level | Service | Result |
|---|------|--------|-------|---------|--------|
| 1 | 14:05 | Signed up at supabase.com (primary email) | L2 | supabase | ACCOUNT CREATED |
| 2 | 14:06 | Stored Supabase API token in keychain | L1 | supabase | TOKEN STORED |
| 3 | 14:07 | Logged in to vercel.com (primary email) | L2 | vercel | LOGGED IN |

v1.3.0 — Execution Flow and Audit Log

Autopilot v1.3.0 — Execution Flow & Audit Log

Two major improvements to how Autopilot executes tasks and tracks what it does.

Execution Flow Protocol (replaces Startup Protocol)

The agent no longer pauses between steps to ask what to do next.

Two flows based on task complexity:

• Flow A (simple tasks) — single service, Level 1-2: executes immediately with brief status updates, no plan or confirmation needed.
• Flow B (complex tasks) — multi-step, multi-service, or Level 3+: presents a numbered plan, waits for one "proceed", then executes everything end-to-end without stopping.

The No-Pause Rule: once execution starts, the agent runs to completion. It only stops for genuine blockers (2FA codes, missing credentials, Level 4+ decisions). "What should I do next?" is no longer in its vocabulary.

Project-Local Execution Log

Every action is now automatically logged to:

{your-project}/.autopilot/log.md

Each session gets a timestamped table with:

• Step number
• Timestamp
• What was done
• Decision level (L1-L5)
• Which service
• Result (done, failed + error)

This is especially useful for Level 1-2 actions that execute silently — the log is the only record of what happened. If something breaks at step 5 of 8, open the log to see exactly what steps 1-4 did, where step 5 failed, and what steps 6-8 were supposed to do.

The log lives in the project directory, not in the autopilot system files. Each project has its own audit trail. Credential values are never logged.

Example

User: Set up Supabase and deploy to Vercel
Autopilot: Here's the plan:
  1. Install Supabase CLI
  2. Create project
  3. Run migrations
  4. Deploy to Vercel preview
  5. Set environment variables
Proceed?

User: yes

Autopilot: [1/5] Supabase CLI already installed
           [2/5] Creating project... done
           [3/5] Running migrations... 2 tables created
           [4/5] Deploying... https://myapp.vercel.app
           [5/5] Env vars set

Done. All actions logged to .autopilot/log.md