Autopilot

e2a Autopilot

Autopilot turns one existing e2a inbox into an always-on local agent trigger. It uses the current e2a protection and CLI surfaces; it does not require or propose server, API, database, SDK, MCP, or core-CLI changes.

Use tether instead when the owner wants to steer an already-running interactive session by email. Use a cloud webhook instead when a stable public service should own the workflow. Autopilot is the local-machine daemon: e2a listen connects outbound, so the machine does not need a public endpoint.

Required conversational behavior

Conduct onboarding as a conversation. Ask one logical question at a time, reflect material answers, explain a tradeoff before asking for a risky opt-out, and skip facts the user already supplied. Do not paste the entire questionnaire.

The interview must establish:

1. The task outcome. Offer the built-in customer-support starter or a custom task.
2. For support: scope, exclusions, approved knowledge, escalation conditions, tone/signature, response expectations, and refund/billing/security/legal limits.
3. An existing e2a inbox and its human owner.
4. One inbound authorization mode: exact sender addresses or verified sender domains. The current protection gate cannot mix both modes on one inbox.
5. Non-matching inbound mail goes to e2a human review. Do not offer a silent bypass or “any authenticated internet sender”; the current surface cannot express the latter safely.
6. Outbound review, default on. Turning it off requires the warning and the exact acknowledgement requested by the interview.
7. Owner CC on every reply, default on. Turning it off requires a warned acknowledgement.
8. Prompt-injection screening, recommended and default on. Turning it off requires a warned acknowledgement.
9. Claude Code, Codex, Hermes Agent, or a custom executable; its absolute path, workspace, and isolation mode. (OpenClaw is unavailable in this release: its invocation flags are unverified.) Hermes and custom executables require an acknowledged external isolation boundary because Autopilot cannot verify one for them. A built-in container runner is not implemented in this release; use an explicitly reviewed custom wrapper.
10. launchd, systemd, or foreground operation.

Use the plugin-local entrypoint for the authoritative interview and policy. autopilot.sh sits in this skill's own directory, next to this SKILL.md. Substitute its absolute path for $AUTOPILOT in every command below; the script resolves its own resources, so any working directory works.

"$AUTOPILOT" interview

It saves after every answer and can resume.

Confirmation is a hard boundary

Render the deterministic plan after onboarding:

"$AUTOPILOT" plan

Show the complete output, limitations, and 64-character plan digest to the user. Then ask for confirmation of that exact digest. A casual earlier “yes,” approval of the design, or permission to continue polishing is not installation approval.

Only after the user confirms the displayed digest may you run:

"$AUTOPILOT" install --confirm <digest>

install is visibly mutating. It uses the operator's current account-scoped e2a CLI session to verify inbox ownership, save the existing protection document, mint one dedicated agent-scoped supervisor key, apply the confirmed protection, verify it, and create owner-only local state and a secret-free service definition. It rolls back protection and revokes the new key if installation fails. It never stores the account credential.

Installation deliberately does not start the service. Starting an always-on agent is a second intentional action. Ask before running:

"$AUTOPILOT" start --agent support@example.com

Never start Autopilot merely because install succeeded.

Enforced architecture

The supervisor owns the agent-scoped e2a key. A task runtime never receives an e2a key, MCP credential, forward token, or arbitrary mailbox access. Each job gets a new local socket and capability exposing only:

• current-message (read)
• current-thread (read)
• reply (submit)
• escalate
• complete

The gateway binds reads and replies to the current job, chooses reply recipients from the existing thread, and injects the owner CC when configured. It has no list, search, delete, arbitrary-recipient, key-management, protection, or review- approval operation. Do not “help” a runtime by adding direct e2a MCP or CLI access.

Inbound delivery is defense in depth:

• e2a's existing protection gate allows the selected authenticated senders and sends every non-match to human review;
• the local receiver independently refuses an event that does not match policy;
• prompt-injection screening is a separate content check for allowed mail; and
• a message released by a reviewer is found by listener delivery or periodic unread reconciliation.

Durable metadata-only jobs move through pending, running, retry, done, and dead. Message bodies are fetched only for the active job and are not written to the spool or logs. Stale running jobs recover after restart. Listener bouncing and independent unread reconciliation cover silent WebSocket gaps.

Runtime isolation

Adapters are one-shot and receive a sanitized environment plus the job gateway. Claude Code and Codex run with their session-persistence, MCP inheritance, and user config disabled; Hermes uses one-shot safe mode. None of these adapter flags is treated as an isolation boundary by itself.

For every job the harness also wraps the runtime process in a per-job OS sandbox when one is available: sandbox-exec on macOS (an allow-default profile with file-read* denies) or bwrap on Linux (tmpfs mask over the install root). The sandbox denies reads of the Autopilot install root's credential, policy, state, and log files while leaving the confirmed workspace and the network usable — coding agents need their own LLM APIs. When neither tool exists the runtime runs unwrapped, and the acknowledged external-isolation model below remains the mitigation.

The OS account is still a trust boundary. A hostile process running as the same user may inspect owner-readable files outside the denied set or process state. A prompt that says “do not read secrets” is not a sandbox; do not describe it as one.

Operations

# Foreground debugging
"$AUTOPILOT" run --agent support@example.com

# Service lifecycle
"$AUTOPILOT" start --agent support@example.com
"$AUTOPILOT" stop --agent support@example.com

# Local status; --verify temporarily uses the current account CLI session to
# compare observable e2a protection fields with the installed policy.
"$AUTOPILOT" status --agent support@example.com
"$AUTOPILOT" status --agent support@example.com --verify

# Paths only by default; add --follow to tail
"$AUTOPILOT" logs --agent support@example.com --follow

After starting, verify all of these before declaring success:

1. Status reports the service running and status --verify reports matches-policy.
2. Logs show the loopback receiver and supervisor starting without secret values.
3. An authorized synthetic sender creates one job and a reply stays in-thread, CCs the owner, and enters outbound review when enabled.
4. A non-authorized synthetic sender is held by e2a review and creates no local runtime job.
5. Releasing that held message makes reconciliation enqueue it once.
6. Restarting the service neither loses nor duplicates durable work.

Use only synthetic addresses and content in repository fixtures and public logs.

Uninstall

Show the uninstall plan and require the literal confirmation DELETE:

"$AUTOPILOT" uninstall \
  --agent support@example.com --confirm DELETE

Uninstall stops the service, revokes its dedicated key, removes the service definition, and moves local state to a recoverable timestamped archive. It does not restore the pre-install protection automatically: an administrator may have changed it later, and a blind restore could overwrite intentional security work.

Truthful limitations

Always disclose these in the plan:

1. Owner CC is enforced by the local gateway, not the server.
2. Account administrators can later change protection; the daemon has no durable revision signal. status --verify is an explicit drift check.
3. The current CLI puts the listener forward token in a child-process argument, visible to the same OS user.
4. Public-any-authenticated-sender mode is not supported in this release.
5. Human reviewers are trusted and can edit an approved outbound message.