autopilot-ai 2.1.0 → 2.2.0

package/README.md

@@ -236,6 +236,20 @@ autopilot -p "..." --dangerously-allow-all          # auto-approve mutating tool
 autopilot -p "..." --reasoning                      # include chain-of-thought in stderr
 ```
 
+### Run tasks on your own server
+
+Send a task to an Autopilot server you run. It works in its own sandbox and opens a pull request, and you can close your laptop while it does.
+
+```sh
+autopilot remote add https://acme.example.com      # approve the code in your browser; no keys copied
+autopilot --on acme "fix the flaky checkout test"  # runs on the server; uncommitted changes go along
+autopilot runs                                     # what's running or done, with PR links
+autopilot runs watch <run>                         # follow a run (Ctrl-C detaches, the run keeps going)
+autopilot pull <run>                               # check out the run's branch here
+```
+
+The run starts from the last commit your branch shares with `origin`. Unpushed commits, staged and unstaged edits, and untracked files that aren't ignored are sent along as a patch, up to 3 MiB. Add `--detach` to return right away and `-m <model>` to pick one of the server's models. Each task gets its own sandbox and branch, so several can run at once. The server keeps the model key and GitHub credentials; your laptop holds only a revocable, 90-day pairing credential in `~/.config/autopilot/remotes.json`. Setting up the server side is covered in [docs/aster-api.md](docs/aster-api.md).
+
 ### Headless SDK
 
 Use autopilot programmatically from your own application — no TUI required.
@@ -532,12 +546,12 @@ still read (see [Settings location](#settings-location)):
 
 | Event              | Fires when                                      | Veto? |
 |--------------------|-------------------------------------------------|-------|
-| `SessionStart`     | A session's first turn (`source`: startup/resume) | No  |
+| `SessionStart`     | A session's first prompt, before `UserPromptSubmit` (`source`: startup/resume) | No  |
 | `PreToolUse`       | A tool call is about to run                     | Yes   |
 | `PostToolUse`      | A tool call just finished (success or failure)  | No    |
 | `PostToolUseFailure` | A tool call failed (also fires `PostToolUse`) | No    |
 | `PermissionRequest` | You're about to be asked to approve a call     | Allow / deny |
-| `UserPromptSubmit` | You hit Enter on a prompt                       | Yes   |
+| `UserPromptSubmit` | A prompt is submitted, in every mode (TUI, `-p`, `--emit-events`, `serve`, SDK) | Yes   |
 | `Stop`             | A turn ended cleanly                            | No    |
 | `PreCompact`       | Auto-compaction is about to run                 | No    |
 | `SessionEnd`       | autopilot exits, or `/clear` (`reason`)         | No    |
@@ -553,7 +567,17 @@ prefer reading stdin. Payloads
 also carry Claude Code's field names (`hook_event_name`, `tool_name`,
 `tool_input`, `tool_response`, `tool_call_id`, `transcript_path`), so
 Claude Code hook scripts — and tools built for them, like
-[Agent Beacon](docs/beacon.md) — work unchanged.
+[Agent Beacon](docs/beacon.md) — work unchanged. A successful
+`write`/`edit`'s `tool_response` carries Claude Code's `structuredPatch`
+and `originalFile` (and `type: "create" | "update"` for `Write`); see
+[docs/beacon.md](docs/beacon.md#tool-names-and-result-shapes) for the
+size limits.
+
+A blocked `UserPromptSubmit` never reaches the model: the TUI shows the
+reason, `-p` and one-shot `--emit-events` exit with code **44**,
+`serve` answers `403 prompt_blocked`, and the SDK's `prompt()` rejects
+with `PromptBlockedError` (details in
+[docs/beacon.md](docs/beacon.md#session-and-prompt-events)).
 #### Blocking and exit codes
 
 Veto events (`PreToolUse`, `UserPromptSubmit`) follow Claude Code's rules: