name the sandbox's working directory, and drive phases through it

Two features, one shared reason: what the sandbox calls things decides
what a run tells you afterwards.

The cwd is now mounted at the path it has on the host and that is the
working directory, so pwd, an error the agent quotes, a commit message and
the window title a harness derives from the cwd all name this project
instead of reading the same as every sandbox in the session. The mount is
unchanged: same directory, same rw, same :z, still the only writable one.

Only the destination changed, and a destination is where a bind mount can
do damage -- it hides whatever the image already had there. So
mirror_block_of() refuses the paths the image or the sandbox owns (/usr,
/etc, /var, /opt, /bin, /sbin, /lib*, /boot, /proc, /sys, /dev, /root,
/run, /tmp, /home, /home/sandbox*) and / itself, while /home/<user>/...
mirrors: the one standard hierarchy where work lives, and the one whose
per-user tree never meets the container's /home/sandbox volume or the
read-only .agents share inside it.

/tmp is what set the shape, and it was measured rather than assumed: with
--tmpfs /tmp and -v /tmp/x:/tmp/x in one run podman puts the tmpfs on top,
so pwd prints the right path, writes succeed, and the project is not there.
A failure that quiet earns a refusal plus a line of output instead:
workdir_note in --print-policy, a comment in --dry-run, one log line on a
real run. --workdir DIR still chooses the mount point; onto a refused path
it is honoured (it was asked for) and warned about. /project, the one
directory baked into the image, is every fallback, so a workdir always
exists -- --no-cwd included.

ai-sandbox-autophase runs a .agents/phases/ pipeline with the split the
sandbox forces: every executor agent and the .agents/validate.sh gate
inside, the commits and the pushes outside. The gate is in the writable
mount, so running it on the host is running agent-editable bash on the
host; the git remote is deliberately unreachable in there, because an agent
that can push can ship what you are about to review. It runs your launcher,
not a copy of it -- the definition is read out of your rc files and never
called, which is what lets --status and --dry-run promise no token fetch,
no build, no container. Host git runs with an empty hooks path and no ext::
transport, and delivery is refused if a sandboxed unit rewrote .git/config
or planted a hook. Needs --no-interactive to go with --no-tty: an
unattended run must not leave stdin open on your keyboard, and the two are
now separate choices on both sides.

Tests and tooling, most of it forced by what the two changes exposed:
mirror_block_of is extracted from the script and asked about /usr and
/home/sandbox, which a test cannot create (the 06_entrypoint.sh pattern),
and both real branches are driven from a scratch dir under $HOME, since
$TMPDIR is always the fallback -- which is why the whole suite had only
ever seen /project. e2e/12 holds a real container to the same promise,
including that /project, /home/sandbox and a home-volume marker survive a
mirrored run. The "nothing was started" checks now compare the set of
container ids before and after instead of counting every sandbox on the
machine, so a session you have open is not a test failure; the pty cases
fall back to python3 where util-linux's script is not installed.
shellcheck covers both programs, the completion file and the fixtures, so
the completion builds are word-by-word now, and a colon in the project path
is refused with the reason instead of podman's "invalid option type".

558 unit assertions, 719 with e2e; lint and bash -n clean.

LLM-Generated: true

docs/networking.md

@@ -72,6 +72,8 @@ name itself.
 | `--pids-limit 64 --memory 256m --cpus 0.5` | `pids.max=64`, `memory.max=268435456` visible inside | limits are real (note: `/proc/cpuinfo` still lists all cores; use `nproc`/cgroup limits, not cpuinfo) |
 | `-v $dir:/project` with SELinux enforcing, `--userns=keep-id:uid=1000,gid=1000` | write **denied** | bind mounts need `:z` on SELinux hosts |
 | same, with `:z` | write succeeds, file owned by the host uid (1000:1000) | project files keep sane ownership |
+| `--tmpfs /tmp` **and** `-v /tmp/x:/tmp/x` in one run | the tmpfs wins: `mount` shows `tmpfs on /tmp/x`, `pwd` prints `/tmp/x`, writes succeed | a project mounted at its own path under `/tmp` would be an empty, writable, correctly-named directory that is not the project — so `mirror_block_of()` refuses `/tmp` rather than degrading quietly |
+| `-v $dir:$dir` (a per-user path) beside the `/tmp` tmpfs, the `/home/sandbox` volume and the `.agents` share | `pwd` is the host path, writes land on the host owned by the host uid, `/project` + the home volume + the share all still there | mirroring buries nothing outside the denied set; asserted per release in `tests/e2e/12_sandbox.sh` |
 
 ## Why not the other designs
 

docs/recipes.md

@@ -236,3 +236,93 @@ registry.npmjs.org
 
 Then `pi` alone in that directory is the whole invocation — and because both files
 are in the repository, the sandbox policy gets reviewed with the code.
+
+## An unattended pipeline: phases in the sandbox, pushes on the host
+
+The nightly case: `.agents/phases/todo/` full of task files, nobody watching, an
+agent that must not be able to reach the git remote or touch the host.
+
+```bash
+# ~/.bashrc.d/ai-sandbox.bash -- the launcher, the way you already write it
+sandbox-pi () {
+    export AI_API_TOKEN=$(pass aipi/dev-token)
+    ai-sandbox --allow aipi.reeseapps.com --allow github.com \
+               --allow pi.dev --allow release-assets.githubusercontent.com \
+               --env AI_API_TOKEN
+}
+```
+
+```bash
+cd ~/Projects/foo
+ai-sandbox-autophase --status     # what it resolved, what is pending, the git plan
+ai-sandbox-autophase --dry-run    # the exact child and gate commands, nothing run
+ai-sandbox-autophase              # every pending task, in pipeline order
+```
+
+What it does with that function is the interesting part. A script cannot see an
+interactive shell's functions, so it reads the rc files, takes the *definition*, and
+starts each child as:
+
+```
+sandbox-pi --no-tty --no-interactive -- pi --no-approve --session-dir .agents/phase-sessions --name <unit> --mode json <prompt>
+```
+
+`pass` runs again per unit, so a run that starts at 23:00 is not holding a token
+fetched at 09:00. Reading the definition is all the probe does: `--status` and
+`--dry-run` never call the launcher, fetch a token, build an image or start a
+container.
+
+| you want | flag |
+|---|---|
+| a different launcher | `--pi-cmd sandbox-claude`, `--pi-cmd pi`, or a whole command line |
+| the function somewhere else | `--rc-files ~/.bashrc.d/zz-ai.bash` |
+| fewer flags of its own | `--sandbox-args ''` (the defaults are `--no-tty --no-interactive`) |
+| the gate on the host, because the toolchain lives there | `--validate-in host` (warns: the gate file is in the writable mount) |
+| one task, one phase, a short run | `--unit 03_api/02_routes.md`, `--phase 03_api`, `--max-units 4` |
+| commits that stay local while you watch | `--no-push` |
+| no warm-up container (it costs a build the first time) | `--no-preflight` |
+
+Where the work goes when it finishes: the executor agents never commit; the driver
+commits each completed phase on the host and pushes it, checks again before starting
+the next phase, and pushes whatever is left at the end of the run. A failed push
+stops the run and prints the command that finishes it — the commit is never lost, and
+the next run's push sweeps it up:
+
+```
+[2026-10-28 02:14:07] pushing 1 unpushed commit(s) on main (between 03_api and 04_docs)
+  (pushed: 9f1c2ab phase: 03_api)
+```
+
+Inside the sandbox the agent has the repository but not the remote, and it is told so
+in its own prompt (`--no-notes` to drop that block) — `git status`, `git diff`, `git
+log` work; `git push`, `fetch`, `pull` and `clone <url>` are not attempted, so no
+fixer round is spent rediscovering that. That is also why the gate runs in the sandbox:
+`.agents/validate.sh` is inside the writable mount, and a jailer the prisoner can edit
+is not a jailer.
+
+One consequence of committing out here is worth naming: a repository is not only what
+git records, it is what git **runs** — `.git/config`, and `.git/hooks/` especially. So
+the driver's git calls run with an empty hooks path, no pager, no system config and no
+`ext::` transport, and the run refuses to deliver if a sandboxed unit changed either:
+
+```
+✗ ERROR: refusing to deliver (commit/push) -- the sandbox changed this repository's own git configuration.
+    look at it by hand:  git config --local --list;  ls -l .git/hooks
+    if the change was yours:  re-run with --trust-git-changes
+```
+
+The commits and the work stay exactly where they are; nothing is pushed and no hook
+runs either way.
+
+A project whose tests need something the image lacks gets it from the launcher:
+
+```bash
+sandbox-pi () {
+    export AI_API_TOKEN=$(pass aipi/dev-token)
+    ai-sandbox --allow aipi.reeseapps.com --allow pypi.org --allow files.pythonhosted.org \
+               --install 'python3-pip ripgrep' --env AI_API_TOKEN
+}
+```
+
+`doctor`, `inspect`, `clean` and the rest of ai-sandbox work unchanged underneath it —
+`--status` prints the policy the launcher will apply, without applying it.

docs/threat-model.md

@@ -34,6 +34,8 @@ registry you don't control, or someone with access to your host user account.
 | Writing to the host's package manager, `/etc`, global npm/pip | read-only-ish image, `HOME` inside the container, optional `--read-only` | `tests/e2e/12_sandbox.sh` |
 | Credential persistence you did not ask for | `--ephemeral-home`; the default home volume is named and inspectable | `tests/e2e/12_sandbox.sh` |
 | Silent wide-open starts | an empty allowlist in `allow` mode is a hard error | `tests/unit/01_args.sh` |
+| An agent shipping work you have not looked at (`git push`) | the git remote is not in the allowlist, so nothing in the container can reach it; `ai-sandbox-autophase` commits and pushes on the host, outside the sandbox, between unit runs | `tests/unit/10_autophase.sh` |
+| The gate becoming the escape (`validate.sh` is inside the writable mount) | the pass/fail gate runs in the sandbox as the same unprivileged user, not on the host | `tests/unit/10_autophase.sh` |
 
 ## What does **not** stop it
 
@@ -97,6 +99,14 @@ Be honest about these, and design your work accordingly.
     re-forced every run so a run cannot quietly lower the reasoning of the next. It is
     not eliminated: `--ephemeral-home` removes it, and `inspect` shows what is bridged.
 
+13. **A push on the host still pushes what the agent wrote.** `ai-sandbox-autophase`
+   keeps the remote away from the sandbox, but somebody has to deliver the work, and
+   that somebody is the harness running as you. It commits only the phase's own
+   changes and only after `.agents/validate.sh` passes — so read that gate as part of
+   your trust base. It lives in the writable mount, which is exactly why the gate runs
+   *in the sandbox* by default; `--validate-in host` hands that judgement to you and
+   warns on every run.
+
 ## Residual risk rating
 
 *Accidental destruction and ambient credential leakage: largely eliminated.*