fix(install): install into a private venv when pipx is absent

The harness's second run hit the wall the first one predicted: a fresh account
has no pipx, so install.sh fell to `pip install --user`, and every Python a Mac
offers — Homebrew and python.org alike — is externally managed, so PEP 668
blocked it. That fallback was never a fallback on macOS; it was a dead end that
printed instructions.

Replace it with a venv at ~/.bot-bottle/venv (BOT_BOTTLE_VENV to move it),
with the console script symlinked into ~/.local/bin. PEP 668 does not apply
inside a venv, and venv is stdlib, so unlike pipx there is nothing to bootstrap
first. pipx stays the preferred path when present, so anyone already managing
their Python apps that way is unaffected — and the post-install PATH check now
asks pipx for PIPX_BIN_DIR instead of assuming ~/.local/bin.

Keeping the venv under ~/.bot-bottle rather than ~/.local/share means the whole
footprint stays in one directory, which is what lets the throwaway-account
teardown remain a complete reset.

This removes the PEP 668 pre-flight and the sysconfig user-scheme lookup, both
of which existed only to serve the --user path. Their tests go with them:

* `detects_externally_managed_python` asserted the check that is now moot;
  replaced by one asserting pipx is still preferred when present.
* `checks_pip_usable_before_fallback` pinned a pip probe that no longer runs;
  replaced by one asserting the venv's own pip does the install, since using
  the base interpreter's would install outside the venv.
* `resolves_user_scripts_dir_not_hardcoded` and
  `macos_user_scheme_is_not_dot_local_bin` guarded the ~/Library/Python
  scripts-dir lookup. Nothing installs there now. The surviving "don't
  hardcode" concern is pipx's bin dir, which has its own test.

Five tests are added for the new path: the venv fallback exists, no --user path
survives, the venv is under the config dir, venv creation failure names
python3-venv (Debian ships it separately), and the entry point is exposed
outside the venv.

Verified end to end in a sandbox HOME with a fresh-account PATH and no pipx:
venv built, package installed, symlink created, `doctor` reached and green
(python 3.14.5, macos-container ready), exit 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WEfZZhakx13bxTfXcZCoS5

README.md

@@ -71,7 +71,21 @@ When the agent exits, `cli.py` tears down every gateway and both networks; nothi
 
 ## Quickstart
 
-On compatible macOS hosts, the default backend requires Apple's `container` CLI and does not require Docker. The Firecracker backend (Linux) requires Docker on the host for the gateway plus the `firecracker` binary and KVM. The legacy Docker backend requires Docker. Claude bottles also need a long-lived Claude Code OAuth token (`claude setup-token`) exported as `BOT_BOTTLE_CLAUDE_OAUTH_TOKEN`.
+```sh
+curl -fsSL https://gitea.dideric.is/didericis/bot-bottle/raw/branch/main/install.sh | sh
+```
+
+The installer is a bootstrapper: it finds a suitable Python, installs bot-bottle with `pipx` (falling back to `pip --user`), creates `~/.bot-bottle`, and runs `bot-bottle doctor`. It is idempotent and never uses `sudo`. Python-native users can skip it entirely with `pipx install bot-bottle` or `uv tool install bot-bottle`.
+
+### Requirements
+
+**Python ≥ 3.11**, and this is the one that trips people up on macOS: the `python3` Apple ships at `/usr/bin/python3` is **3.9.6**, which is too old. Bare `python3` resolves to that stub far more often than people expect. `path_helper` builds a login shell's `PATH` from `/etc/paths` and then appends `/etc/paths.d/*`, and `/usr/bin` sits in the former — so even when `/opt/homebrew/bin` *is* on the `PATH` (via `/etc/paths.d/homebrew`), it comes after `/usr/bin` and loses. Prepending a newer Python is something your shell profile does, and a fresh account, a launchd job, or a CI runner has no such profile. So the installer looks past bare `python3` before giving up: it tries `python3`, then the versioned `python3.11`–`python3.14` names, then `/opt/homebrew/bin`, `/usr/local/bin`, `~/.local/bin`, and python.org framework builds — and tells you which one it picked when it isn't the obvious one. Point it somewhere specific with `BOT_BOTTLE_PYTHON=/path/to/python3`.
+
+**No `pipx` required.** If `pipx` is present the installer uses it and stays out of the way. If it isn't, bot-bottle installs into a private venv at `~/.bot-bottle/venv` (override with `BOT_BOTTLE_VENV`) and symlinks the entry point into `~/.local/bin`. There is deliberately no `pip install --user` path: Homebrew, python.org and Debian/Ubuntu interpreters are all externally managed (PEP 668), which blocks `--user` outright — so on a Mac it is never the fallback it appears to be. A venv is exempt from PEP 668, and `venv` is stdlib, so unlike `pipx` there is nothing to bootstrap first.
+
+**`git`**, because the default install spec is a `git+` URL. Set `BOT_BOTTLE_INSTALL_SPEC` to a wheel path or index name to avoid it.
+
+**A backend**, which the installer deliberately does *not* install for you — `doctor` reports what's missing afterwards. On compatible macOS hosts, the default backend requires Apple's `container` CLI and does not require Docker. The Firecracker backend (Linux) requires Docker on the host for the gateway plus the `firecracker` binary and KVM. The legacy Docker backend requires Docker. Claude bottles also need a long-lived Claude Code OAuth token (`claude setup-token`) exported as `BOT_BOTTLE_CLAUDE_OAUTH_TOKEN`.
 
 Use `BOT_BOTTLE_BACKEND=docker ./cli.py start <agent>` on hosts where neither Apple Container nor KVM is available and Docker is the desired backend.
 

docs/research/agent-sandbox-landscape.md

@@ -32,9 +32,17 @@ not a principled scope exclusion: both are major hosted sandbox platforms and
 belong in this landscape even though they target platform builders rather than
 bot-bottle's local single-operator workflow.
 
+Updated 2026-07-27 after a scan of recent Show HN launches: **Black LLAB,
+Eve, CloudRouter, Nucleus, yolo-cage, and Sandbox Agent SDK** added as a
+dated entrant cohort. They sharpen the comparison on three axes the original
+table underweighted: the browser/preview loop, parallel-agent operator UX, and
+a provider-neutral automation/session API.
+
 ## Summary
 
-The main table compares bot-bottle against fifteen isolation/sandbox tools.
+The main table compares bot-bottle against fifteen canonical
+isolation/sandbox tools; a later section evaluates six recent HN entrants
+without widening an already unwieldy table.
 Governance/pre-action authorization and credential-only layers are covered
 separately because they don't provide VM or container isolation. None
 duplicate bot-bottle's combination of local
@@ -542,6 +550,199 @@ them.
   framework runtime is not compromised.
 - **Maturity**: Specification + reference implementation, 2026.
 
+## Recent HN entrants (added 2026-07-27)
+
+These are grouped by launch date rather than promoted into the main table.
+Several are young or sparsely documented, and putting them beside mature
+runtime platforms with false precision would obscure the useful comparison.
+The HN launch posts are the evidence snapshot; feature claims should be
+rechecked against their repositories before relying on them for a security
+decision.
+
+### Black LLAB
+
+- **Source**: https://github.com/isaacdear/black-llab ;
+  HN launch https://news.ycombinator.com/item?id=47402394
+- **Isolation/locality**: Local Docker environment, with an isolated container
+  created for each agent task. Shared host kernel; no stronger boundary is
+  claimed.
+- **Agent integration**: General local/cloud model workspace. Its headline is
+  dynamic routing of simple prompts to local models and complex prompts to
+  hosted models, with code execution and web scraping inside the task
+  container.
+- **Network/credentials**: No default-deny egress, payload inspection, or
+  host-side credential injection documented in the launch.
+- **Competitive read**: Superficial overlap ("a container per agent task"),
+  but not a direct security-policy competitor. Its useful challenge is the
+  integrated model-selection UX, which bot-bottle intentionally leaves to the
+  selected agent provider.
+- **Maturity**: Early solo project; HN launch received 1 point.
+
+### Eve
+
+- **Source**: https://eve.new/ ;
+  HN launch https://news.ycombinator.com/item?id=47721255
+- **Isolation/locality**: Managed, hosted Linux sandbox per user/session
+  (claimed 2 vCPU, 4 GB RAM, 10 GB disk), with filesystem, code execution,
+  headless Chromium, and service connectors.
+- **Agent integration**: End-user OpenClaw-style agent product. An orchestrator
+  routes subtasks to specialist models and can run parallel subagents that
+  coordinate through a shared filesystem. Web UI and iMessage are primary
+  interaction surfaces.
+- **Network/credentials**: Broad connectors are a product feature; the launch
+  does not document bot-bottle-style default-deny route policy, content DLP,
+  or credentials held outside the sandbox.
+- **Competitive read**: Adjacent, not direct. Eve sells a managed colleague;
+  bot-bottle lets an operator run existing coding-agent CLIs under local
+  containment. Eve nevertheless demonstrates the appeal of background work,
+  live progress, browser capability, and mobile notification.
+- **Maturity**: Commercial hosted product; HN launch received 71 points and
+  39 comments.
+
+### CloudRouter
+
+- **Source**: https://github.com/manaflow-ai/manaflow/tree/main/packages/cloudrouter ;
+  HN launch https://news.ycombinator.com/item?id=47006393
+- **Isolation/locality**: Claude Code or Codex runs locally and provisions
+  remote cloud VMs/GPUs for execution. Project files are uploaded to the VM;
+  each machine exposes auth-protected VNC, VS Code, and Jupyter surfaces.
+- **Agent integration**: A skill plus CLI lets the coding agent itself start,
+  command, inspect, and tear down machines. Browser automation is integrated,
+  including snapshots and screenshots. Parallel disposable compute is the
+  central workflow.
+- **Network/credentials**: The launch emphasizes remote resource isolation and
+  authenticated UI endpoints, not default-deny guest egress, payload DLP, or
+  proxy-held application credentials.
+- **Competitive read**: The closest recent workflow competitor. It directly
+  addresses parallel coding agents, environmental conflict, and closing the
+  browser/test loop, but trades local custody for elastic cloud compute.
+  Cloud VMs and GPUs could be a future bot-bottle backend; they do not replace
+  its manifest/policy layer.
+- **Maturity**: Active open-source monorepo project; HN launch received
+  138 points and 36 comments.
+
+### Nucleus
+
+- **Source**: https://github.com/coproduct-opensource/nucleus ;
+  HN launch https://news.ycombinator.com/item?id=46855770
+- **Isolation/locality**: Firecracker microVM with an enforcing MCP tool proxy.
+- **Agent integration/config**: Compositional permission envelope for
+  read/write/run actions. The envelope is non-escalating and can tighten or
+  terminate, with scoped approval tokens for gated operations.
+- **Network/credentials**: Default-deny egress, DNS allowlist, iptables drift
+  detection, time/budget caps, and hash-chained audit logging are claimed.
+  Remote append-only audit storage and attestation were roadmap items at
+  launch.
+- **Competitive read**: Direct on security architecture, especially
+  non-escalating policy and tamper-evident audit. It is an early execution/tool
+  proxy rather than a provider-neutral, one-command coding-agent product. Its
+  tool-level action envelope is semantically finer than bot-bottle's network
+  boundary; bot-bottle is stronger on turnkey agent/provider integration,
+  credential custody, Git mediation, and long-running operator workflow.
+- **Maturity**: Early OSS experiment; HN launch received 3 points.
+
+### yolo-cage
+
+- **Source**: https://github.com/borenstein/yolo-cage ;
+  HN launch https://news.ycombinator.com/item?id=46706796
+- **Isolation/locality**: Local sandbox for running multiple coding agents in
+  YOLO mode. The launch discussion describes a VM boundary.
+- **Agent integration**: Built around the native Claude Code experience and
+  motivated by running many agents in parallel without permission-prompt
+  fatigue.
+- **Network/Git/credentials**: Strict egress filtering, configurable HTTP
+  middleware, and mediated `git`/`gh` dispatch are the main value. The launch
+  discussion explicitly identifies provider credential handling as unfinished
+  and difficult because Claude state spans multiple host paths.
+- **Competitive read**: The closest new threat-model competitor. It shares
+  bot-bottle's premise that filesystem isolation alone is insufficient and
+  that Git plus authorized HTTP channels need mediation. bot-bottle currently
+  leads on cross-provider support, proxy-held Claude/Codex/forge credentials,
+  typed per-role manifests, content DLP, and supervision. yolo-cage's simpler
+  pitch and narrower Claude-first setup may be easier to explain.
+- **Maturity**: Early local tool; HN launch received 60 points and 76 comments.
+
+### Sandbox Agent SDK
+
+- **Source**: https://github.com/rivet-dev/sandbox-agent ;
+  HN launch https://news.ycombinator.com/item?id=46795584
+- **Isolation/locality**: Does not provide the isolation primitive. It runs
+  inside E2B, Daytona, Modal, Cloudflare Containers, Agent Computer, BoxLite,
+  Docker, or another sandbox provider. Embedded mode can also run locally
+  without a sandbox.
+- **Agent integration**: Provider-neutral Rust server/SDK exposing a common
+  HTTP/SSE/OpenAPI interface across Claude Code, Codex, OpenCode, Cursor, Amp,
+  and Pi, plus a universal event/session schema for external storage and
+  replay. It also exposes filesystem, managed-process, terminal, MCP, skills,
+  custom-tool, and computer-use APIs. TypeScript is the primary SDK surface.
+- **Network/credentials**: Delegated to the chosen sandbox provider.
+- **Credential posture**: Its documented convenience command extracts real
+  OpenAI/Anthropic credentials from local agent configuration and passes them
+  as environment variables into the sandbox. That is materially weaker than
+  bot-bottle's host-side credential custody, but it is an integration choice,
+  not a structural limitation: a sandbox provider could put a credential
+  proxy underneath the same SDK.
+- **Competitive read**: A serious architectural threat despite not supplying
+  isolation. Sandbox Agent is trying to standardize the boundary *above* the
+  sandbox: one client protocol, session model, and UI/control surface across
+  every coding agent and runtime. If that boundary becomes the ecosystem
+  standard, users and application builders may choose a sandbox provider plus
+  Sandbox Agent rather than a vertically integrated launcher. bot-bottle's
+  manifests would then be valuable chiefly as a local policy/backend
+  implementation unless they expose an equally usable control contract.
+- **Maturity**: Apache 2.0, ~1.5k stars and 426 commits at the 2026-07-27
+  check; HN launch received 41 points.
+
+#### Why the Sandbox Agent architecture is strategically different
+
+The manifest and the universal control protocol solve different layers:
+
+- A bot-bottle manifest is a **trusted launch-time policy composition**. It
+  selects the agent role, isolation backend, image, skills, egress routes,
+  credentials, Git mediation, and supervision policy. Crucially, identity and
+  secret references live on the host side of the trust boundary.
+- Sandbox Agent is a **runtime control and observation protocol**. A remote
+  client creates sessions, sends messages, handles permissions, configures
+  skills/MCP, manipulates files/processes/desktops, and streams normalized
+  events. It deliberately delegates sandbox lifecycle, Git management,
+  storage, network policy, and credential security to other products.
+
+That makes it complementary in a component diagram but competitive in product
+architecture. The layer that becomes the stable integration point tends to own
+the ecosystem. Three plausible threat paths matter:
+
+1. **Standard control plane, interchangeable runtimes.** Applications integrate
+   once with Sandbox Agent and treat E2B, Daytona, BoxLite, Docker, or a future
+   local microVM as replaceable compute. A provider that bundles adequate
+   egress and credential custody makes bot-bottle's end-to-end launcher less
+   necessary.
+2. **Policy grows upward.** Sandbox Agent already configures permissions,
+   skills, MCP, custom tools, filesystem/process access, and computer use. If
+   it adds a declarative, host-verifiable policy document, the overlap with
+   agent/bottle manifests becomes substantial even if enforcement remains
+   delegated.
+3. **UI and session ownership.** Its universal transcript schema, Inspector,
+   React components, event replay, and remote terminal/computer APIs can become
+   the natural basis for desktop, web, and mobile agent managers. bot-bottle's
+   security layer could remain stronger while losing the operator surface and
+   distribution channel.
+
+The counter-position is not to claim that manifests and an API are mutually
+exclusive. The defensible split is:
+
+- bot-bottle owns the trusted policy and enforcement plane outside the agent;
+- a provider-neutral protocol owns agent process control and normalized
+  events; and
+- the operator UI consumes both.
+
+This suggests an explicit compatibility decision rather than parallel,
+accidental protocol design: evaluate running Sandbox Agent inside a bottle and
+exposing it only through the authenticated bot-bottle control plane. If its
+schema is suitable, adopting it could turn a threat into an integration while
+keeping manifests as the higher-trust policy source. If it is unsuitable,
+bot-bottle should still publish a stable provider-neutral session/event API so
+frontends do not depend on Claude/Codex/Pi-specific process behavior.
+
 ## Comparison table
 
 *Isolation/sandbox tools only. AGT and OAP are governance layers — see their per-project notes above.*
@@ -616,6 +817,70 @@ would be a *backend* bot-bottle could call, not a competitor to its
 manifest layer. endo-familiar is in a different paradigm entirely:
 capability passing rather than kernel boundaries.
 
+**Recent entrants change two parts of this read.** yolo-cage is closer to the
+actual threat model than agent-safehouse or litterbox: it combines a VM-style
+boundary with mediated Git and filtered HTTP specifically for parallel coding
+agents. Sandbox Agent SDK is the more important strategic entrant even though
+it supplies no isolation. It can become the standard agent-control layer above
+all of these runtimes, including a future bot-bottle backend. CloudRouter is
+the clearest workflow challenge because its browser/desktop/GPU loop makes
+parallel agents visibly more capable, not merely safer.
+
+## Gap evaluation after the 2026-07-27 entrant scan
+
+### Material gaps
+
+1. **A stable provider-neutral control and event protocol.** This is the
+   largest newly visible gap. bot-bottle normalizes launch/provisioning across
+   providers, but an external UI or orchestrator still lacks one documented
+   contract for creating a Claude/Codex/Pi session, sending input, handling
+   permission/supervision events, streaming normalized output, reconnecting,
+   and replaying history. Sandbox Agent SDK addresses exactly this layer and
+   is already portable across many sandbox providers.
+2. **Browser/preview closure.** CloudRouter and Eve make a browser or desktop
+   part of the standard agent environment and expose screenshots/live viewing
+   to the operator. bot-bottle can run dev servers and supports nested
+   containers, but it does not present a first-class browser/computer-use
+   primitive or an auth-protected preview surface. For coding agents expected
+   to verify UI work, this is a real product gap.
+3. **Unified parallel-session operator UX.** Named persistent bottles and
+   supervision provide the substrate, but the recent products make task
+   switching, live progress, notifications, terminal attach, diffs, and
+   session history the product. Security depth will not compensate for a
+   visibly rougher daily loop.
+4. **Normalized transcript persistence and replay.** bot-bottle preserves
+   provider-specific state for resume; it does not expose a provider-neutral
+   event record suitable for audit, replay, analytics, or a web/mobile client.
+   This is both a UX gap and an audit gap.
+
+### Important, but not necessarily bot-bottle features
+
+- **Cloud VM/GPU provisioning.** Valuable for elastic workloads and could be a
+  backend, but it conflicts with the local-custody default and should not
+  displace core policy work.
+- **Automatic model routing.** Black LLAB and Eve sell task-to-model routing.
+  bot-bottle's provider-template boundary can host that choice without making
+  it part of the trusted sandbox policy.
+- **A thousand SaaS connectors.** This broadens capability and blast radius.
+  The bot-bottle-native answer should remain explicit, scoped forge/egress
+  associations rather than connector count as a goal.
+- **SDK-driven sandbox lifecycle as the primary configuration model.** Useful
+  for platform builders, but not a replacement for reviewable, host-owned
+  manifests. A control API and a declarative policy source are compatible;
+  neither should silently become the other.
+
+### Areas where bot-bottle remains ahead
+
+- real provider and forge credentials remain outside the agent process rather
+  than being extracted into its environment;
+- authorized HTTP payloads are scanned, not merely destination-filtered;
+- Git writes traverse a distinct gate with secret scanning and host-held
+  upstream credentials;
+- role policy is host-owned, composable, and separate from untrusted repo
+  content; and
+- local Firecracker/Apple Container execution preserves operator custody
+  without requiring a hosted sandbox platform.
+
 ## Borrowable ideas
 
 ### Already shipped or otherwise addressed
@@ -642,6 +907,19 @@ capability passing rather than kernel boundaries.
 
 ### Still worth considering
 
+- **Sandbox Agent compatibility or an equivalent stable protocol (highest
+  priority):** spike running its server inside a bottle behind bot-bottle's
+  authenticated control plane. Compare its session/event schema, permission
+  model, restore semantics, and provider coverage with current provider
+  adapters. Adopt compatibility if it preserves the host-owned trust boundary;
+  otherwise specify bot-bottle's own stable API before building another UI.
+- **First-class browser/preview loop** (from CloudRouter and Eve): give a
+  bottle an optional browser/computer-use capability plus an operator-visible,
+  authenticated preview/screenshot surface. Treat its network access as part
+  of the bottle policy, not an implicit bypass.
+- **Provider-neutral transcript/event persistence** (from Sandbox Agent SDK):
+  retain enough normalized structure for replay and audit while preserving the
+  provider-native state needed for exact resume.
 - **Live network activity in the supervisor TUI** (from Docker sbx): show
   allowed and blocked connections and let the operator propose policy changes
   from the existing supervision surface.
@@ -652,10 +930,11 @@ capability passing rather than kernel boundaries.
   closer review. This needs a carefully specified trust model before it can be
   more than a heuristic.
 
-Not worth borrowing: the SDK-first programmatic API style of boxlite /
-microsandbox (cuts against the declarative-manifest stance), and the
-hosted-SaaS dashboard model of tilde.run (cuts against the
-"infrastructure I control" goal).
+Not worth borrowing: SDK-first *policy configuration* as used by boxlite /
+microsandbox (cuts against the reviewable declarative-manifest stance), and
+the hosted-SaaS custody model of tilde.run (cuts against the "infrastructure I
+control" goal). A provider-neutral runtime-control API is a separate concern
+and is worth borrowing.
 
 ## Publishing and positioning verdict
 
@@ -679,9 +958,15 @@ bot-bottle remains unusual in combining:
 The practical wedge is “as easy as native yolo, with declarative role policy
 and self-hosted custody,” including scoped access to private LAN/Tailnet
 services that cloud-first runtimes cannot provide without additional network
-plumbing. The main competitive risks are a local wrapper such as claudebox or
-Docker sbx growing a role-manifest layer, and GUI products such as SuperHQ
-adding equivalent policy and audit depth.
+plumbing. The main competitive risks are now:
+
+- a local wrapper such as yolo-cage, claudebox, or Docker sbx growing a
+  role-manifest and credential-custody layer;
+- Sandbox Agent SDK becoming the standard control/session boundary and making
+  the runtime beneath it interchangeable; and
+- GUI products such as SuperHQ or CloudRouter adding equivalent policy and
+  audit depth before bot-bottle closes the browser/preview and
+  parallel-session UX gaps.
 
 ## Caveats
 

docs/research/testing-clean-install-on-macos.md

@@ -0,0 +1,258 @@
+# Testing a clean bot-bottle install on macOS
+
+How do you exercise `install.sh` (and, ideally, a first `bot-bottle start`)
+the way a brand-new user would — on a pristine macOS environment you can
+throw away afterward — *without* permanently polluting your daily-driver
+Mac? The user's framing: is there a VM or boundary that avoids creating a
+separate account, or is spinning up and tearing down a throwaway macOS
+user on the CLI easy enough to just do that?
+
+## Summary
+
+There is no lightweight, in-place macOS sandbox that hands you a clean home
+directory and wipeable system state without *either* a VM or a separate
+user account. `sandbox-exec` (Seatbelt) is deprecated and confines a
+process, not an environment; App Sandbox is for shipping apps, not for
+provisioning a fresh dev host. So the real choice is exactly the two the
+user named: **a disposable macOS VM** or **a throwaway user account** —
+and which one is right turns on a detail specific to *this* project.
+
+bot-bottle's default macOS backend is Apple's `container`, which runs each
+container in its own lightweight VM via `Virtualization.framework`
+([`README.md:27`](../README.md), [`apple-container-backend.md`](apple-container-backend.md)).
+That means a full end-to-end test — install *and* `bot-bottle start` —
+needs virtualization to work wherever bot-bottle runs. Inside a macOS guest
+VM that requires **nested virtualization, which Apple gates to M3 or newer
+chips on macOS 15+**. On M1/M2 you cannot run the Apple Container backend
+(or Docker Desktop, same reason) inside a macOS VM at all.
+
+The recommendation splits on what you're testing and what silicon you have:
+
+- **Install-script correctness only** (does `curl | sh` → pipx → config dir
+  → `doctor`'s Python/config checks pass?): a **disposable Tart VM** is the
+  cleanest boundary and works on any Apple Silicon Mac. `doctor` will report
+  the backend as not-ready inside the VM on M1/M2, which is fine — you're
+  testing the installer, not the runtime.
+- **Full runtime** (actually launch a bottle) on **M3/M4**: a **disposable
+  Tart VM from a golden base image, cloned per run** is the gold standard —
+  a genuine kernel/state boundary that wipes to nothing.
+- **Full runtime** on **M1/M2**, or when you'd rather not fight nested virt:
+  a **throwaway admin user via `sysadminctl`** is the pragmatic pick. It
+  tests the real backend because the backend runs on the host hypervisor —
+  but it is a *hygiene* boundary, not a security one, and it does **not**
+  clean the system-level footprint (see below).
+
+Prefer the VM. Reach for the throwaway user only when nested virt is off the
+table and you accept an imperfect wipe.
+
+## Why "a boundary without a separate user" doesn't really exist on macOS
+
+macOS has no namespace/overlay story like Linux `unshare` + tmpfs. The
+options that sound like in-place sandboxes don't fit:
+
+| Mechanism | Why it doesn't give you a clean, wipeable env |
+|---|---|
+| `sandbox-exec` / Seatbelt | Officially deprecated; confines *one process's* syscalls against a profile. It cannot present a fresh `$HOME` or a pristine `/usr/local`, and it won't let the Apple Container system service work. |
+| App Sandbox | Entitlement-based confinement for signed `.app` bundles, not a provisioning tool for a CLI dev environment. |
+| A second `$HOME` via `HOME=/tmp/foo` | Redirects only what honors `$HOME`. `install.sh` mostly does (it writes `~/.bot-bottle` and pipx/pip `--user` paths), but the Apple `container` install lands in `/usr/local` + a **system service**, and Homebrew lands in `/opt/homebrew` — all outside any `$HOME` you set. You'd get a false sense of "clean." |
+| APFS snapshot rollback (`tmutil localsnapshot`) | You can't roll the live boot volume back to a local snapshot without booting to Recovery; it's not a per-run userspace undo. |
+
+So the honest answer to "is there some boundary that avoids a separate
+user?": yes — a **VM** — and it's the *stronger* boundary anyway. The only
+lighter-weight option is the separate user, with the caveats below.
+
+## What a clean install actually touches (the footprint that decides "wipeable")
+
+Grounding the teardown story in what `install.sh` and the backend create:
+
+| Artifact | Location | In `$HOME`? | Survives user deletion? |
+|---|---|---|---|
+| Config / state / db | `~/.bot-bottle/{agents,bottles,contrib,state,db}` ([`install.sh:80-83`](../install.sh), [`bot_bottle/paths.py:59`](../bot_bottle/paths.py)) | ✅ | ❌ removed with home |
+| pipx venv + shim | `~/.local/pipx/venvs/bot-bottle`, shim in `~/.local/bin` ([`install.sh:87-89`](../install.sh)) | ✅ | ❌ removed with home |
+| private venv fallback (no pipx) | `~/.bot-bottle/venv` + symlink in `~/.local/bin` ([`install.sh`](../install.sh)) | ✅ | ❌ removed with home |
+| PATH / token exports | shell profile (`~/.zprofile`, etc.); `BOT_BOTTLE_CLAUDE_OAUTH_TOKEN` ([`README.md:74`](../README.md)) | ✅ | ❌ removed with home |
+| **Apple `container` install** | `/usr/local/...` + notarized `.pkg` receipts | ❌ | ✅ **stays** |
+| **Apple `container` system service** | launchd system service (`container system start`) | ❌ | ✅ **stays** |
+| **Homebrew** (if used for `container`/python) | `/opt/homebrew` | ❌ | ✅ **stays** |
+| Rosetta 2 (needed for image builds) | system | ❌ | ✅ **stays** |
+
+The three bold rows are the crux: **deleting the throwaway user does not
+uninstall the Apple Container runtime, its system service, Homebrew, or
+Rosetta.** A VM, by contrast, wipes 100% of the above by definition —
+that's its entire advantage for this task.
+
+## Option A — Disposable Tart VM (recommended)
+
+[Tart](https://tart.run) is a CLI-first macOS/Linux VM manager built on
+`Virtualization.framework`, purpose-built for exactly this "does it work on
+a clean macOS, without my settings/permissions/data" workflow. Keep one
+pristine *golden* image, clone a throwaway per run, delete it after.
+
+```sh
+brew install cirruslabs/cli/tart
+
+# One-time: build a golden base (either a prebuilt image or a vanilla IPSW).
+tart clone ghcr.io/cirruslabs/macos-tahoe-base:latest golden   # ~25 GB pull
+# — or a truly vanilla install you click through once —
+# tart create golden --from-ipsw latest --disk-size 60
+
+# Per test run: clone → boot → test → destroy.
+tart clone golden test-run
+tart run test-run &
+ssh admin@"$(tart ip test-run)"
+#   inside the guest:
+#   curl -fsSL https://gitea.dideric.is/didericis/bot-bottle/raw/branch/main/install.sh | sh
+#   bot-bottle doctor
+tart stop test-run
+tart delete test-run          # back to pristine; golden is untouched
+```
+
+Cloning is cheap (sparse files), so the golden image is your reset button —
+every `tart clone` is a fresh macOS. This is the closest thing to a Linux
+`docker run --rm` for a whole Mac.
+
+**The nested-virt caveat (read before relying on it for runtime tests).**
+The Apple Container backend inside the guest needs
+`Virtualization.framework` to work *inside* the VM. Apple enables nested
+virtualization only on **M3 or newer**, on **macOS 15 (Sequoia) or later**;
+M2 and earlier are excluded by Apple, confirmed by Apple DTS. Consequences:
+
+- **M3/M4 host:** full runtime works in the guest. `bot-bottle doctor`
+  reports the backend ready and `start` can launch a bottle. Gold standard.
+- **M1/M2 host:** the guest can install bot-bottle and pass the Python /
+  config-dir checks, but `doctor`'s backend check will fail and you cannot
+  launch a bottle in the VM. Still perfectly good for testing *the
+  installer*; not for the runtime.
+- **M4-specific:** a known bug blocks pre-Ventura guests on M4; use a
+  current macOS guest (which you want anyway, since Apple `container`
+  targets macOS 26 Tahoe).
+
+UTM is the GUI equivalent on the same framework (and was first to expose
+nested virt) if you'd rather click; Tart wins for a scriptable
+spin-up/tear-down loop.
+
+## Option B — Throwaway user via `sysadminctl` (pragmatic fallback)
+
+Creating and deleting a user from the CLI is genuinely a two-liner, and it
+tests the **real** backend on any Apple Silicon Mac because the backend runs
+on the host hypervisor — no nested virt needed.
+
+```sh
+# Create a self-contained admin user (admin needed for the container service).
+sudo sysadminctl -addUser bbtest -fullName "bot-bottle test" \
+    -password 'throwaway' -admin
+
+# Log into that account (fast-user-switch or the login window), then run the
+# installer as bbtest exactly as a new user would. When done:
+
+sudo sysadminctl -deleteUser bbtest -secure   # -secure erases the home dir
+```
+
+Honest accounting of what this does and doesn't buy you:
+
+- **Boundary strength:** it's a *hygiene / fresh-`$HOME`* boundary, **not a
+  security boundary.** Same kernel, same admin group; an admin test user can
+  touch system state. If the point is "clean environment," fine. If the point
+  is "contain something untrusted," this is the wrong tool — use a VM.
+- **Wipe completeness:** `-secure` erases the home dir (so `~/.bot-bottle`,
+  the pipx venv, and profile exports go away), but as the footprint table
+  shows, the **Apple Container runtime, its launchd system service,
+  Homebrew, and Rosetta persist.** For a truly repeatable "did a *system with
+  nothing installed* work?" test, that residue defeats the purpose — the
+  second run isn't clean.
+- **Operational gotchas:** don't pass real passwords on the command line (they
+  land in `ps` and history — this is a throwaway credential, so it's
+  tolerable here). Deletion must run as root from a normally-booted, admin-
+  logged-in session; the Terminal needs **Full Disk Access** or you'll hit
+  error `-14120` and a half-deleted account. Prefer letting the system place
+  the home dir (don't pass `-home`), or deletion can orphan it.
+
+Use this when you're on M1/M2, you specifically want to exercise the live
+backend, and you can tolerate the system-level runtime staying installed
+between runs (or you uninstall Apple `container` / brew by hand to reset).
+
+## Honorable mentions
+
+- **External bootable macOS volume.** A fresh macOS on an external SSD (or a
+  separate APFS volume) is bare-metal disposable: no nested-virt limit, real
+  backend works, and you `diskutil` the volume away to reset. Cost is reboot
+  friction per run — good for an occasional thorough pass, poor for a tight
+  loop.
+- **Rented / cloud Mac.** AWS EC2 Mac (dedicated Mac minis), Scaleway Apple
+  silicon, or MacStadium give a genuinely throwaway host you release when
+  done. Overkill for local iteration, but this is essentially what the
+  project's own advisory `integration-macos` CI job needs — a self-hosted
+  Apple Silicon runner with the `container` CLI, Python ≥ 3.11, and coverage
+  on the launchd service's PATH ([`README.md:78`](../README.md)). If you end
+  up standing up a cloud Mac for install testing, it doubles as that runner.
+
+## Recommendation
+
+Default to a **disposable Tart VM** — it's the only option that wipes the
+*entire* footprint (including the Apple Container system service that a user
+deletion leaves behind), it's a real boundary, and the spin-up/tear-down
+loop is a two-command `tart clone` / `tart delete`. Confirm your chip first:
+on **M3/M4** it tests install *and* runtime end-to-end; on **M1/M2** it still
+cleanly tests `install.sh` + `doctor`'s Python/config path, and you fall back
+to a **throwaway `sysadminctl` admin user** for live-backend testing —
+accepting that it's a hygiene boundary and that you'll manually uninstall the
+Apple Container runtime / Homebrew between runs to get back to truly clean.
+
+There is no third, lighter-weight "in-place boundary without a user" that
+actually delivers a clean, wipeable macOS — the VM *is* that answer, and it's
+the better one.
+
+## Harness
+
+The throwaway-user loop is scripted in
+[`scripts/macos-install-test.sh`](../../scripts/macos-install-test.sh):
+`up` creates the account, `run` pipes *this checkout's* `install.sh` into it
+headlessly (so a PR is verifiable before it lands) and lets the installer run
+`doctor`, `down` deletes the account and its home (the full reset), and
+`deep-reset` additionally uninstalls the host `container` runtime. It leans on
+the footprint analysis above — the reset is just user deletion because
+everything `install.sh` writes is user-home-local.
+
+`test` chains `up → run → status → down` into the one-shot cycle you normally
+want:
+
+```sh
+sudo ./scripts/macos-install-test.sh test
+```
+
+It refuses to start against an existing account (a reused home is not a clean
+install), and it tears the account down from an `EXIT`/`INT` trap armed the
+moment the account exists, so a failed or Ctrl-C'd run still leaves the machine
+clean. Its verdict is deliberately stricter than the installer's own: note that
+`install.sh` exits **0** when it finishes but `doctor` reports unmet
+prerequisites, so "the installer succeeded" is not the assertion — `test` fails
+if the install fails, if `bot-bottle` never reached the new user's `PATH`, or if
+`doctor` is unhappy. `BB_TEST_KEEP=1` skips the teardown to poke at a failure.
+
+### What a fresh account actually inherits
+
+Expect the first honest run on a developer Mac to fail at the *Python* gate,
+and expect that to be correct. A new account's `PATH` is just `/etc/paths`
+(`/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin`),
+which notably does **not** include `/opt/homebrew/bin`. Homebrew's `shellenv`
+line lives in the *installing* user's `~/.zprofile` and is not inherited, so a
+throwaway user resolves `python3` to `/usr/bin/python3` — the Command Line
+Tools stub, still **3.9.6** on macOS 26 — and `install.sh` correctly dies on its
+`3.11+` requirement. Your own shell resolving `python3` to a 3.14 Homebrew
+build says nothing about what a new user sees; that gap is exactly what this
+harness exists to expose.
+
+## Sources
+
+- [Apple Containers on macOS: technical comparison with Docker — The New Stack](https://thenewstack.io/apple-containers-on-macos-a-technical-comparison-with-docker/)
+- [How to Set Up Apple Containerization on macOS 26 — Stéphane Paquet](https://spaquet.medium.com/how-to-set-up-apple-containerization-on-macos-26-f870cc8c26cd)
+- [Install Apple Container CLI (macOS 15/26) — 4sysops](https://4sysops.com/archives/install-apple-container-cli-running-containers-natively-on-macos-15-sequoia-and-macos-26-tahoe/)
+- [Nested virtualization on Apple Silicon (M3+, macOS 15) — UTM issue #6700](https://github.com/utmapp/UTM/issues/6700)
+- [macOS 15 Sequoia nested virtualization for M3+ — Parallels Forums](https://forum.parallels.com/threads/macos-15-sequoia-nested-virtualization-for-m3-macs.364397/)
+- [M2 nested virtualization restriction (Apple DTS) — Apple Developer Forums](https://developer.apple.com/forums/thread/756723)
+- [M4 can't virtualize older macOS — Yahoo/Tech](https://tech.yahoo.com/computing/articles/m4-mac-computers-cant-virtualize-175122301.html)
+- [Tart — macOS/Linux VMs on Apple Silicon (Cirrus Labs)](https://tart.run/quick-start/)
+- [Tart GitHub](https://github.com/cirruslabs/tart)
+- [macOS VMs in a single command — frr.dev](https://www.frr.dev/posts/tart-macos-vms-from-terminal/)
+- [sysadminctl reference — SS64](https://ss64.com/mac/sysadminctl.html)
+- [User management from the macOS command line — macnotes](https://macnotes.wordpress.com/2019/03/28/user-management-create-remove-change-password-secure-token-from-macos-command-line/)

install.sh

@@ -8,14 +8,20 @@
 #   pipx install bot-bottle        # from a checkout or a published index
 #   uv tool install bot-bottle
 #
-# This script is a thin bootstrapper: it checks prerequisites, installs the
-# package with pipx (falling back to pip --user), creates the config dir, and
-# runs `bot-bottle doctor`. It is idempotent (safe to re-run) and never uses
-# sudo. It does NOT install Docker or a VM backend for you — `doctor` reports
-# what's missing after install.
+# This script is a thin bootstrapper: it finds a Python 3.11+ interpreter,
+# installs the package with pipx (falling back to a private venv), creates the
+# config dir, and runs `bot-bottle doctor`. It is idempotent (safe to re-run)
+# and never uses sudo. It does NOT install Docker or a VM backend for you —
+# `doctor` reports what's missing after install.
+#
+# Env:
+#   BOT_BOTTLE_PYTHON        interpreter to install with (skips the search)
+#   BOT_BOTTLE_INSTALL_SPEC  pip/git spec to install instead of the default
+#   BOT_BOTTLE_VENV          where the non-pipx install lives (~/.bot-bottle/venv)
 set -eu
 
 PACKAGE_SPEC="${BOT_BOTTLE_INSTALL_SPEC:-git+https://gitea.dideric.is/didericis/bot-bottle.git}"
+VENV="${BOT_BOTTLE_VENV:-${HOME}/.bot-bottle/venv}"
 MIN_PYTHON_MAJOR=3
 MIN_PYTHON_MINOR=11
 
@@ -28,17 +34,97 @@ die() {
     exit 1
 }
 
-# --- prerequisites -----------------------------------------------------------
+# --- prerequisites: find an interpreter new enough ----------------------------
 
-command -v python3 >/dev/null 2>&1 \
-    || die "python3 ${MIN_PYTHON_MAJOR}.${MIN_PYTHON_MINOR}+ is required but was not found"
-
-python3 - "$MIN_PYTHON_MAJOR" "$MIN_PYTHON_MINOR" <<'PY' || die "python3 ${MIN_PYTHON_MAJOR}.${MIN_PYTHON_MINOR} or newer is required"
+# Is $1 an interpreter that exists and meets the floor?
+python_ok() {
+    [ -n "${1:-}" ] || return 1
+    command -v "$1" >/dev/null 2>&1 || return 1
+    "$1" - "$MIN_PYTHON_MAJOR" "$MIN_PYTHON_MINOR" <<'PY' >/dev/null 2>&1
 import sys
 
 want = (int(sys.argv[1]), int(sys.argv[2]))
 raise SystemExit(0 if sys.version_info[:2] >= want else 1)
 PY
+}
+
+python_version() {
+    "$1" -c 'import sys; print("%d.%d.%d" % sys.version_info[:3])' 2>/dev/null
+}
+
+# `python3` on PATH is often NOT the newest interpreter installed, and on macOS
+# it is usually the oldest: a fresh login shell's PATH is just /etc/paths, so
+# python3 resolves to the Command Line Tools stub (3.9.x) while the usable
+# 3.11+ build sits in /opt/homebrew/bin or a python.org framework directory,
+# reachable only via a line in the *installing* user's shell profile. A new
+# account inherits none of that. Look past PATH before giving up, so the common
+# case installs instead of dead-ending on a version error.
+find_python() {
+    for candidate in \
+        "${BOT_BOTTLE_PYTHON:-}" \
+        python3 \
+        python3.14 python3.13 python3.12 python3.11 \
+        /opt/homebrew/bin/python3 \
+        /usr/local/bin/python3 \
+        "${HOME}/.local/bin/python3" \
+        /Library/Frameworks/Python.framework/Versions/*/bin/python3
+    do
+        # An unmatched glob arrives here literally; python_ok rejects it.
+        if python_ok "$candidate"; then
+            command -v "$candidate"
+            return 0
+        fi
+    done
+    return 1
+}
+
+# An explicit choice that doesn't work is an error, not a reason to quietly
+# search elsewhere and install somewhere the caller didn't ask for.
+if [ -n "${BOT_BOTTLE_PYTHON:-}" ] && ! python_ok "${BOT_BOTTLE_PYTHON}"; then
+    if command -v "${BOT_BOTTLE_PYTHON}" >/dev/null 2>&1; then
+        die "BOT_BOTTLE_PYTHON=${BOT_BOTTLE_PYTHON} is $(python_version "${BOT_BOTTLE_PYTHON}"), "\
+"below the ${MIN_PYTHON_MAJOR}.${MIN_PYTHON_MINOR} floor. Unset it to search for a newer one."
+    fi
+    die "BOT_BOTTLE_PYTHON=${BOT_BOTTLE_PYTHON} is not an executable interpreter."
+fi
+
+PYTHON="$(find_python || true)"
+
+if [ -z "${PYTHON}" ]; then
+    path_python="$(command -v python3 2>/dev/null || true)"
+    if [ -n "${path_python}" ]; then
+        found="the python3 on your PATH is ${path_python} ($(python_version "${path_python}")), which is too old"
+    else
+        found="no python3 was found on your PATH"
+    fi
+    case "$(uname -s)" in
+        Darwin) fix="  brew install python@3.12
+  # or install from https://www.python.org/downloads/macos/
+  # macOS itself ships only /usr/bin/python3, which is too old" ;;
+        *) fix="  sudo apt install python3.12    # Debian/Ubuntu
+  sudo dnf install python3.12    # Fedora/RHEL" ;;
+    esac
+    die "bot-bottle needs python3 ${MIN_PYTHON_MAJOR}.${MIN_PYTHON_MINOR} or newer, and none was found.
+  ${found}.
+  Also checked: python3.11-3.14, /opt/homebrew/bin, /usr/local/bin,
+  ~/.local/bin, and python.org framework builds.
+
+Install a newer Python, then re-run this installer:
+${fix}
+
+Already have one somewhere? Point at it directly:
+  BOT_BOTTLE_PYTHON=/path/to/python3 sh install.sh"
+fi
+
+# Be explicit when the interpreter isn't the obvious one, so nobody is left
+# wondering which Python their install ended up on.
+path_python="$(command -v python3 2>/dev/null || true)"
+if [ "${PYTHON}" != "${path_python}" ]; then
+    say "using ${PYTHON} ($(python_version "${PYTHON}"))"
+    if [ -n "${path_python}" ]; then
+        say "note: 'python3' on your PATH is ${path_python} ($(python_version "${path_python}")), which is below the ${MIN_PYTHON_MAJOR}.${MIN_PYTHON_MINOR} floor"
+    fi
+fi
 
 # Installing a `git+` spec (the default) shells out to git under the hood,
 # whether via pipx or pip. Fail early with a clear message rather than deep
@@ -51,30 +137,6 @@ case "${PACKAGE_SPEC}" in
         ;;
 esac
 
-# The pip fallback needs a usable pip. Externally-managed interpreters
-# (PEP 668, common on Debian/Ubuntu/Homebrew) reject `pip install --user`;
-# pipx sidesteps that, so recommend it when pip can't be used.
-if ! command -v pipx >/dev/null 2>&1; then
-    python3 -m pip --version >/dev/null 2>&1 || die \
-        "neither pipx nor a usable 'python3 -m pip' was found. Install pipx "\
-"(recommended): 'python3 -m pip install --user pipx' or your OS package manager."
-    if python3 - <<'PY'
-import os
-import sys
-import sysconfig
-
-# PEP 668: an EXTERNALLY-MANAGED marker in the stdlib dir means pip refuses
-# to install into this interpreter without --break-system-packages.
-marker = os.path.join(sysconfig.get_path("stdlib"), "EXTERNALLY-MANAGED")
-raise SystemExit(0 if os.path.exists(marker) else 1)
-PY
-    then
-        die "this Python is externally managed (PEP 668), so 'pip install --user' is "\
-"blocked. Install pipx and re-run: 'python3 -m pip install --user --break-system-packages pipx', "\
-"then 'pipx ensurepath'."
-    fi
-fi
-
 # --- config directories ------------------------------------------------------
 
 mkdir -p \
@@ -84,32 +146,43 @@ mkdir -p \
 
 # --- install -----------------------------------------------------------------
 
+BIN_DIR="${HOME}/.local/bin"
+
 if command -v pipx >/dev/null 2>&1; then
-    say "installing with pipx"
-    pipx install --force "${PACKAGE_SPEC}"
+    # --python pins the venv to the interpreter we vetted. Without it pipx uses
+    # whichever Python it was itself installed with, which is not necessarily
+    # the one that passed the version check above.
+    say "installing with pipx (python: ${PYTHON})"
+    pipx install --python "${PYTHON}" --force "${PACKAGE_SPEC}"
+    # Ask pipx where it puts entry points rather than assuming ~/.local/bin.
+    pipx_bin="$(pipx environment --value PIPX_BIN_DIR 2>/dev/null || true)"
+    [ -n "${pipx_bin}" ] && BIN_DIR="${pipx_bin}"
 else
-    say "pipx not found; installing with 'python3 -m pip install --user'"
-    python3 -m pip install --user --upgrade "${PACKAGE_SPEC}"
+    # No `pip install --user` fallback: PEP 668 makes it unusable on nearly
+    # every interpreter a Mac offers (Homebrew and python.org are both
+    # externally managed), and on Debian/Ubuntu too. A private venv sidesteps
+    # that entirely — PEP 668 does not apply inside a venv — and `venv` is
+    # stdlib, so unlike pipx there is nothing to bootstrap first.
+    say "pipx not found; installing into a managed venv at ${VENV}"
+    "${PYTHON}" -m venv --clear "${VENV}" || die \
+        "could not create a virtualenv at ${VENV} using ${PYTHON}. On Debian/Ubuntu "\
+"the venv module ships separately: 'sudo apt install python3-venv'."
+    "${VENV}/bin/python" -m pip install --upgrade "${PACKAGE_SPEC}"
+    # Expose the entry point outside the venv, the way pipx would.
+    mkdir -p "${BIN_DIR}"
+    ln -sf "${VENV}/bin/bot-bottle" "${BIN_DIR}/bot-bottle"
 fi
 
 # --- locate the entry point --------------------------------------------------
 
-# The pip --user scripts directory is platform-specific: ~/.local/bin on Linux,
-# but ~/Library/Python/<X.Y>/bin on a python.org macOS interpreter. Ask the
-# interpreter for its own user-scheme scripts dir instead of hardcoding.
-USER_SCRIPTS="$(python3 - <<'PY'
-import sysconfig
-print(sysconfig.get_path("scripts", sysconfig.get_preferred_scheme("user")))
-PY
-)"
-
 if command -v bot-bottle >/dev/null 2>&1; then
     BOT_BOTTLE_BIN="bot-bottle"
-elif [ -n "${USER_SCRIPTS}" ] && [ -x "${USER_SCRIPTS}/bot-bottle" ]; then
-    BOT_BOTTLE_BIN="${USER_SCRIPTS}/bot-bottle"
-    say "note: add ${USER_SCRIPTS} to your PATH to run 'bot-bottle' directly"
+elif [ -x "${BIN_DIR}/bot-bottle" ]; then
+    BOT_BOTTLE_BIN="${BIN_DIR}/bot-bottle"
+    say "note: add ${BIN_DIR} to your PATH to run 'bot-bottle' directly:"
+    say "    echo 'export PATH=\"${BIN_DIR}:\$PATH\"' >> ~/.zprofile"
 else
-    die "bot-bottle was installed but is not on PATH; add ${USER_SCRIPTS:-your user scripts dir} to PATH and re-run"
+    die "bot-bottle was installed but no entry point turned up in ${BIN_DIR}"
 fi
 
 # --- verify ------------------------------------------------------------------

scripts/macos-install-test.sh

@@ -0,0 +1,280 @@
+#!/usr/bin/env bash
+# Clean-install test harness for the macOS (Apple `container`) path.
+#
+# Exercises install.sh the way a brand-new user would, inside a throwaway
+# macOS account you create and delete from the CLI. install.sh's entire
+# footprint is user-home-local — the pipx venv under ~/.local, or the private
+# venv at ~/.bot-bottle/venv plus a ~/.local/bin symlink, and the ~/.bot-bottle
+# config dir. It writes no shell-profile PATH line, and never installs the
+# backend (see
+# the header of install.sh), so deleting the user is a complete,
+# deterministic reset of everything the installer touched. The Apple
+# `container` runtime is a HOST prerequisite installed once and kept;
+# `deep-reset` is the rare escape hatch that also removes it.
+#
+# Why a throwaway user and not a disposable VM: bot-bottle's default macOS
+# backend is Apple `container`, which runs each container in its own
+# Virtualization.framework microVM. Running that backend inside a macOS
+# guest VM needs nested virtualization, which Apple gates to M3+ silicon.
+# On M1/M2 a separate user account is the only way to get a clean $HOME
+# while still reaching the real host backend. Full rationale in
+# docs/research/testing-clean-install-on-macos.md.
+#
+# Usage:
+#   sudo ./scripts/macos-install-test.sh test        # up -> run -> status -> down
+#   sudo ./scripts/macos-install-test.sh up          # create the throwaway user
+#   sudo ./scripts/macos-install-test.sh run         # run install.sh (+doctor) as it
+#        ./scripts/macos-install-test.sh status      # user present? backend ready?
+#   sudo ./scripts/macos-install-test.sh down        # delete user + home (the reset)
+#   sudo ./scripts/macos-install-test.sh deep-reset  # ALSO uninstall host `container`
+#
+# `test` is the one-shot clean cycle and the command you normally want: it
+# refuses to start if the account already exists (a reused home is not a clean
+# install), and it tears the account down on the way out however it exits, so
+# a failed run never leaves an orphan behind. It exits non-zero if the install
+# fails, if `bot-bottle` is missing from the new user's PATH, or if `doctor`
+# reports unmet prerequisites — note install.sh itself exits 0 in that last
+# case, so `test` is a stricter gate than running the installer by hand.
+#
+# Config via env:
+#   BB_TEST_USER         account short name             (default: bbtest)
+#   BB_TEST_FULLNAME     account full name              (default: "bot-bottle install test")
+#   BB_TEST_ADMIN        1=admin (reach container svc), 0=standard  (default: 1)
+#   BB_TEST_INSTALL_URL  curl this install.sh instead of piping the local checkout
+#   BB_TEST_KEEP         1=`test` skips its teardown, to poke at a failure
+#   BOT_BOTTLE_INSTALL_SPEC   passed through to install.sh (pip / git spec)
+#
+# Notes:
+#   * Run from a normally-booted admin session. Grant Terminal *Full Disk
+#     Access* (System Settings -> Privacy & Security) or `down` half-fails
+#     with error -14120 and leaves an orphaned account.
+#   * `sysadminctl` always exits 0 even on failure, so `up`/`down` verify
+#     the result with `dscl` and fail loudly on a mismatch.
+#   * The account is created without a password: `run` drives it headlessly
+#     via `sudo -u`, which never needs the target's password. The account
+#     cannot GUI-login, which this harness does not require.
+#   * `run` covers the installer + `bot-bottle doctor`. Actually launching a
+#     bottle from the throwaway user may need a full launchd user session
+#     (`launchctl asuser`); on M1/M2 the backend can't run under nested virt
+#     anyway, so this harness stops at install + doctor.
+
+set -euo pipefail
+
+USER_NAME="${BB_TEST_USER:-bbtest}"
+FULL_NAME="${BB_TEST_FULLNAME:-bot-bottle install test}"
+ADMIN="${BB_TEST_ADMIN:-1}"
+
+_SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+_REPO_ROOT="$(cd "$_SCRIPT_DIR/.." && pwd)"
+
+# Set by `test`, which chains the steps itself and so suppresses the
+# "here's the next command to run" hints the individual steps print.
+IN_TEST=0
+
+# --- guards ----------------------------------------------------------
+require_macos() {
+    [ "$(uname -s)" = "Darwin" ] \
+        || { echo "error: this harness is macOS-only (uname is $(uname -s))" >&2; exit 1; }
+}
+
+require_root() {
+    if [ "$(id -u)" -ne 0 ]; then
+        echo "error: '$1' needs root; re-run under sudo" >&2
+        exit 1
+    fi
+}
+
+user_exists() { dscl . -read "/Users/$USER_NAME" >/dev/null 2>&1; }
+
+# Run a shell snippet as the throwaway user in a fresh login shell.
+run_as_user() { sudo -u "$USER_NAME" -i sh -c "$1"; }
+
+# `bot-bottle doctor` as the throwaway user. Non-zero when the entry point
+# never made it onto that user's PATH, or when doctor itself is unhappy.
+doctor_as_user() {
+    if ! run_as_user 'command -v bot-bottle >/dev/null 2>&1'; then
+        echo "  bot-bottle is not on PATH for $USER_NAME"
+        return 1
+    fi
+    run_as_user 'bot-bottle doctor'
+}
+
+# --- commands --------------------------------------------------------
+cmd_up() {
+    require_macos
+    require_root up
+    if user_exists; then
+        echo "$USER_NAME already exists; nothing to do (run 'down' first to reset)"
+        return 0
+    fi
+    local admin_flag=()
+    [ "$ADMIN" = "1" ] && admin_flag=(-admin)
+    # No -password: the account is only ever driven headlessly via `sudo -u`,
+    # which doesn't need one. sysadminctl warns about FileVault here; that's
+    # irrelevant to a headless test account.
+    sysadminctl -addUser "$USER_NAME" -fullName "$FULL_NAME" "${admin_flag[@]}" || true
+    # sysadminctl exits 0 regardless of outcome, so confirm the account landed.
+    user_exists || { echo "error: failed to create $USER_NAME" >&2; return 1; }
+    if [ "$IN_TEST" = 1 ]; then
+        echo "created $USER_NAME (admin=$ADMIN)"
+    else
+        echo "created $USER_NAME (admin=$ADMIN). Install into it with: sudo $0 run"
+    fi
+}
+
+cmd_run() {
+    require_macos
+    require_root run
+    user_exists || { echo "error: $USER_NAME does not exist; run 'sudo $0 up' first" >&2; return 1; }
+
+    local spec_env=""
+    [ -n "${BOT_BOTTLE_INSTALL_SPEC:-}" ] \
+        && spec_env="BOT_BOTTLE_INSTALL_SPEC='$BOT_BOTTLE_INSTALL_SPEC' "
+
+    echo "== installing bot-bottle as $USER_NAME =="
+    if [ -n "${BB_TEST_INSTALL_URL:-}" ]; then
+        run_as_user "curl -fsSL '$BB_TEST_INSTALL_URL' | ${spec_env}sh"
+    else
+        # Test THIS checkout's install.sh, not the published one, so a PR is
+        # verifiable before it lands. Feed it in on stdin rather than staging a
+        # copy somewhere the throwaway user can read: the redirect is opened by
+        # root before sudo drops privileges, so the tester's mode-700 home is a
+        # non-issue, there's no temp file to leak if the run is interrupted, and
+        # `sh -s` is the same shape as the documented `curl … | sh` install.
+        run_as_user "${spec_env}sh -s" < "$_REPO_ROOT/install.sh"
+    fi
+    [ "$IN_TEST" = 1 ] \
+        || echo "== install.sh runs 'doctor' itself; re-check anytime with: $0 status =="
+}
+
+# Informational, with one teeth-bearing case: when it can actually reach
+# doctor (root, account present) its exit status is doctor's, so `test` and
+# any other caller can use it as the post-install assertion.
+cmd_status() {
+    require_macos
+    local rc=0
+    if user_exists; then
+        echo "user:    $USER_NAME present"
+        if [ "$(id -u)" -eq 0 ]; then
+            echo "doctor (as $USER_NAME):"
+            doctor_as_user || rc=1
+        else
+            echo "  (re-run under sudo to run 'bot-bottle doctor' as $USER_NAME)"
+        fi
+    else
+        echo "user:    $USER_NAME absent"
+    fi
+    if command -v container >/dev/null 2>&1; then
+        echo "backend: apple 'container' present ($(container --version 2>/dev/null | head -1))"
+    else
+        echo "backend: apple 'container' NOT on PATH (host prerequisite; install once)"
+    fi
+    return "$rc"
+}
+
+cmd_down() {
+    require_macos
+    require_root down
+    if ! user_exists; then
+        echo "$USER_NAME not present; nothing to remove"
+        return 0
+    fi
+    # A plain -deleteUser removes the home dir, which is the whole reset.
+    # -secure is a no-op on modern macOS (secure erase of the home folder
+    # was removed in Sierra), so it buys nothing here.
+    sysadminctl -deleteUser "$USER_NAME" || true
+    if user_exists; then
+        echo "error: $USER_NAME still present after delete." >&2
+        echo "  - grant Terminal Full Disk Access (System Settings > Privacy & Security), or" >&2
+        echo "  - it may hold the last Secure Token (won't happen while another admin exists)" >&2
+        return 1
+    fi
+    echo "removed $USER_NAME and its home — install surface is clean."
+}
+
+# Teardown half of `test`, installed as an EXIT trap the moment the account
+# exists so that a failure — or a Ctrl-C — still leaves the machine clean.
+_test_teardown() {
+    local rc=$?
+    trap - EXIT INT TERM
+    if [ "${BB_TEST_KEEP:-0}" = "1" ]; then
+        echo
+        echo "== [4/4] down: SKIPPED (BB_TEST_KEEP=1) =="
+        echo "   $USER_NAME is still around; remove it with: sudo $0 down"
+        exit "$rc"
+    fi
+    echo
+    echo "== [4/4] down =="
+    cmd_down || rc=1
+    if [ "$rc" -eq 0 ]; then
+        echo
+        echo "PASS: a brand-new user can install bot-bottle and pass doctor."
+    else
+        echo
+        echo "FAIL: see above (the throwaway account was torn down regardless)." >&2
+    fi
+    exit "$rc"
+}
+
+cmd_test() {
+    require_macos
+    require_root test
+    # A pre-existing account means a pre-existing home, which is the one thing
+    # this harness exists to rule out. Don't silently test a dirty install.
+    if user_exists; then
+        echo "error: $USER_NAME already exists, so this would not be a clean install." >&2
+        echo "  reset first:  sudo $0 down" >&2
+        return 1
+    fi
+    IN_TEST=1
+
+    echo "== [1/4] up =="
+    cmd_up
+    trap _test_teardown EXIT INT TERM
+
+    echo
+    echo "== [2/4] run =="
+    cmd_run
+
+    echo
+    echo "== [3/4] status =="
+    # install.sh exits 0 even when doctor reports unmet prerequisites, so the
+    # install succeeding is not the verdict — this is.
+    cmd_status || {
+        echo "error: doctor is unhappy for a freshly installed user (see above)." >&2
+        echo "  re-run with BB_TEST_KEEP=1 to keep $USER_NAME around and dig in." >&2
+        return 1
+    }
+}
+
+cmd_deep_reset() {
+    require_macos
+    require_root deep-reset
+    # Remove the user first (idempotent), then the HOST-level container
+    # runtime that a user deletion leaves behind under /usr/local + launchd.
+    cmd_down || true
+    if command -v container >/dev/null 2>&1; then
+        # The service can run in more than one launchd context (the invoking
+        # user's and root's), so stop both, best-effort.
+        [ -n "${SUDO_USER:-}" ] && sudo -u "$SUDO_USER" container system stop 2>/dev/null || true
+        container system stop 2>/dev/null || true
+        if [ -x /usr/local/bin/uninstall-container.sh ]; then
+            /usr/local/bin/uninstall-container.sh -d || true
+            echo "uninstalled the host Apple 'container' runtime"
+        else
+            echo "note: /usr/local/bin/uninstall-container.sh not found; runtime left as-is" >&2
+        fi
+    else
+        echo "no 'container' runtime on PATH; nothing further to remove"
+    fi
+}
+
+case "${1:-}" in
+    test) cmd_test ;;
+    up) cmd_up ;;
+    run) cmd_run ;;
+    status) cmd_status ;;
+    down) cmd_down ;;
+    deep-reset) cmd_deep_reset ;;
+    *) echo "usage: $0 {test|up|run|status|down|deep-reset}" >&2 ; exit 2 ;;
+esac

tests/unit/test_install_script.py

@@ -9,7 +9,7 @@ create the config tree, install the package, and verify with `doctor`.
 from __future__ import annotations
 
 import os
-import sysconfig
+import re
 import unittest
 from pathlib import Path
 
@@ -17,6 +17,22 @@ REPO_ROOT = Path(__file__).resolve().parents[2]
 INSTALL_SH = REPO_ROOT / "install.sh"
 
 
+def code_only(text: str) -> str:
+    """Script text with string literals and comments removed.
+
+    Both are places the script *talks about* commands rather than running
+    them — remediation advice quite reasonably says "sudo apt install …" —
+    so assertions about what the script actually executes must not see them.
+    Strings are stripped before comments because a '#' inside a quoted string
+    is not a comment, and several literals here span multiple lines.
+    """
+    without_strings = re.sub(r"\"(?:[^\"\\]|\\.)*\"|'[^']*'", "", text)
+    return "\n".join(
+        ln for ln in without_strings.splitlines()
+        if ln.strip() and not ln.lstrip().startswith("#")
+    )
+
+
 class TestInstallScript(unittest.TestCase):
     @classmethod
     def setUpClass(cls):
@@ -32,20 +48,45 @@ class TestInstallScript(unittest.TestCase):
         self.assertIn("set -eu", self.text)
 
     def test_never_uses_sudo(self):
-        # Only executable lines matter; the header comment may mention sudo.
-        code = [
-            ln for ln in self.text.splitlines()
-            if ln.strip() and not ln.lstrip().startswith("#")
-        ]
-        self.assertNotIn("sudo", "\n".join(code))
+        # The installer must never *invoke* sudo. It may print it: the "no
+        # usable python" error suggests 'sudo apt install python3.12'.
+        self.assertNotIn("sudo", code_only(self.text))
 
     def test_creates_config_tree(self):
         self.assertIn(".bot-bottle/agents", self.text)
         self.assertIn(".bot-bottle/bottles", self.text)
 
-    def test_installs_via_pipx_with_pip_fallback(self):
+    def test_installs_via_pipx_with_venv_fallback(self):
         self.assertIn("pipx install", self.text)
-        self.assertIn("pip install --user", self.text)
+        self.assertIn("-m venv", self.text)
+
+    def test_no_pip_user_fallback(self):
+        # `pip install --user` is not a fallback, it's a dead end: PEP 668
+        # blocks it on Homebrew, python.org and Debian/Ubuntu interpreters,
+        # which is every Python a Mac realistically offers. A private venv is
+        # exempt from PEP 668 and needs no bootstrap, since venv is stdlib.
+        # code_only, because the comment explaining the absence says the words.
+        code = code_only(self.text)
+        self.assertNotIn("pip install --user", code)
+        self.assertNotIn("--break-system-packages", code)
+
+    def test_venv_lives_under_the_config_dir(self):
+        # Keeps the whole install footprint inside ~/.bot-bottle (plus the
+        # entry-point symlink), which is what makes deleting a throwaway
+        # account a complete reset in scripts/macos-install-test.sh.
+        self.assertIn(".bot-bottle/venv", self.text)
+        self.assertIn("BOT_BOTTLE_VENV", self.text)
+
+    def test_venv_failure_is_actionable(self):
+        # Debian/Ubuntu ship venv separately; failing there must say so rather
+        # than dumping ensurepip's error.
+        self.assertIn("python3-venv", self.text)
+
+    def test_entry_point_is_exposed_outside_the_venv(self):
+        # A venv's bin dir is never on PATH, so the console script has to be
+        # linked somewhere conventional or `bot-bottle` is unreachable.
+        self.assertIn(".local/bin", self.text)
+        self.assertIn("ln -sf", self.text)
 
     def test_runs_doctor_after_install(self):
         self.assertIn("doctor", self.text)
@@ -60,42 +101,43 @@ class TestInstallScript(unittest.TestCase):
         self.assertIn("command -v git", self.text)
         self.assertIn("git+*|*.git", self.text)
 
-    def test_checks_pip_usable_before_fallback(self):
-        self.assertIn("python3 -m pip --version", self.text)
+    def test_installs_into_the_venv_with_its_own_pip(self):
+        # The venv's pip, not the base interpreter's — the base one may not
+        # exist, and using it would install outside the venv.
+        self.assertIn("${VENV}/bin/python\" -m pip install", self.text)
 
-    def test_detects_externally_managed_python(self):
-        # PEP 668: 'pip install --user' is blocked on externally-managed
-        # interpreters; the script must detect this and point at pipx.
-        self.assertIn("EXTERNALLY-MANAGED", self.text)
-        self.assertIn("pipx", self.text)
+    def test_pipx_is_preferred_when_present(self):
+        # The venv is a fallback, not a takeover: someone who already manages
+        # their Python apps with pipx keeps doing so.
+        self.assertIn("command -v pipx", self.text)
 
-    def test_resolves_user_scripts_dir_not_hardcoded(self):
-        # The pip --user scripts dir differs by platform; the script must ask
-        # the interpreter (sysconfig + the preferred *user* scheme) rather than
-        # hardcoding Linux's ~/.local/bin (which is wrong on macOS python.org).
-        self.assertIn("get_preferred_scheme", self.text)
-        self.assertIn("sysconfig", self.text)
-        # No hardcoded Linux path in executable lines (a comment may mention it).
-        code = "\n".join(
-            ln for ln in self.text.splitlines()
-            if ln.strip() and not ln.lstrip().startswith("#")
-        )
-        self.assertNotIn(".local/bin", code)
+    def test_asks_pipx_where_its_bin_dir_is(self):
+        # PIPX_BIN_DIR is configurable, so the post-install "is it on PATH?"
+        # check must ask rather than assume ~/.local/bin.
+        self.assertIn("PIPX_BIN_DIR", self.text)
 
-    def test_macos_user_scheme_is_not_dot_local_bin(self):
-        # The case the fix exists for: a python.org macOS interpreter uses the
-        # osx_framework_user scheme, whose scripts land under
-        # ~/Library/Python/<X.Y>/bin — NOT ~/.local/bin. Drive the same
-        # sysconfig lookup install.sh uses, with a mac-like userbase, to prove
-        # it resolves a non-~/.local/bin directory.
-        self.assertIn("osx_framework_user", sysconfig.get_scheme_names())
-        scripts = sysconfig.get_path(
-            "scripts", "osx_framework_user",
-            vars={"userbase": "/Users/dev/Library/Python/3.11"},
-        )
-        self.assertEqual("/Users/dev/Library/Python/3.11/bin", scripts)
-        self.assertNotIn("/.local/bin", scripts)
+    def test_searches_beyond_path_for_an_interpreter(self):
+        # `python3` on PATH is the *oldest* interpreter on a stock Mac: a fresh
+        # account's PATH is /etc/paths, so python3 is the 3.9.6 CLT stub while
+        # the usable build sits somewhere only a shell profile puts on PATH.
+        # Giving up at that point dead-ends every new macOS user.
+        for candidate in ("python3.11", "/opt/homebrew/bin", "Python.framework"):
+            self.assertIn(candidate, self.text)
 
+    def test_interpreter_is_overridable(self):
+        self.assertIn("BOT_BOTTLE_PYTHON", self.text)
+
+    def test_pipx_is_pinned_to_the_vetted_interpreter(self):
+        # Without --python, pipx builds the venv with whichever interpreter
+        # pipx itself was installed with, which need not be the one that
+        # passed the version check.
+        self.assertIn("pipx install --python", self.text)
+
+    def test_version_failure_is_actionable(self):
+        # The failure a new macOS user actually hits must say what to do about
+        # it, not just state the requirement.
+        self.assertIn("brew install python@", self.text)
+        self.assertIn("BOT_BOTTLE_PYTHON=/path/to/python3", self.text)
 
 if __name__ == "__main__":
     unittest.main()