anon-pi@0.31.0

Minor Changes

• 26c5159: Adopt netcage's --allow-direct -> --allow flag rename and require netcage >= 0.12.0.

  netcage v0.12.0 renamed its split-tunnel flag --allow-direct -> --allow (and made it port-mandatory), so anon-pi now composes the one direct hole as --allow <host:port> on every launch path (run and container enter -> netcage start); the direct target is unchanged (still the ONE hole, always present with --proxy). The NETCAGE_MIN_VERSION floor moves 0.11.0 -> 0.12.0, now enforced for TWO reasons (the uid-scoped store from 0.11.0 AND the --allow flag from 0.12.0). A LAUNCH-TIME gate at the spawn seam refuses a jail-entering launch on netcage < 0.12.0 (or absent/unparseable) with the upgrade remediation and a non-zero exit BEFORE spawning netcage with the new flag, so a non-hardened install gets clear guidance instead of a raw unknown flag "--allow".

  This is a deliberate BACKWARD-INCOMPATIBLE bump: anon-pi supports netcage >= 0.12.0 only (no dual-flag support, no version-conditional argv). Upgrade netcage to >= 0.12.0.

anon-pi@0.30.1

Patch Changes

• fb90816: Fix -p --mode text-stream so it renders each turn LIVE as it happens, not all at once at the end. The WATCH path used spawnSync, which buffers pi's entire JSONL stdout and only returns it on child exit, so every step surfaced at the very end. It now uses an async spawn with an incremental stdout handler, so each complete line renders the instant it arrives. The final answer is still printed to STDOUT on exit (pipeable), stdin/stderr stay inherited, and the exit code still propagates.

anon-pi@0.30.0

Minor Changes

• 0b333a1: Rename the dedicated hardened-deployment Unix accounts off the generic anon namespace onto anon-pi's own anonpi namespace. The default persona account is now anonpi (was anon) and named personas are anonpi-<name> (was anon-<name>). This is a BREAKING change: an existing hardened install's anon / anon-<name> accounts, their mode-700 homes, sudoers rules, and stored per-persona proxies do not carry over, so re-provision under the new names (anon-pi init, anon-pi persona add <name>) and userdel -r the old ones.

  Why: a sibling tool, anonctl, owns the generic account namespace (the bare anon and the anon-<name> prefix) for a different anonymization model. anon-pi moves to a disjoint namespace so the two tools' accounts never collide on a box that runs both. anonpi has no hyphen after anon, so it is neither the bare anon nor a anon-<name> persona, and no anonpi-<name> can equal anon or anon-<x>. anonpi is also self-documenting and not a common real-world username (unlike pi).

  A new namespace guard in validatePersonaName rejects a persona name that is exactly anon or starts with anon-, keeping anon-pi's and anonctl's account spaces disjoint and preventing a confusing anonpi-anon… account. The ANON_ACCOUNT ('anonpi') and PERSONA_ACCOUNT_PREFIX ('anonpi-') constants, personaAccount/personaName, the generated Tier-2 provisioning + teardown commands, the sudo -u <account> crossing, the /home/<account> assumptions, the per-persona Tor SOCKS-isolation username, the init/persona help text, and the README all move to the new scheme. The anon-pi package name, the anon-pi.* netcage labels, the ~/.anon-pi workspace dir, and the /etc/sudoers.d/anon-pi-<account> file prefix are the tool name and are unchanged.

anon-pi@0.29.7

Patch Changes

• 568b62a: Fix: init / persona must not be redirected into the account (they provision it and cross themselves).

  On a hardened install the launch self-re-exec (sudo -u anon -i anon-pi "$@") ran before subcommand dispatch, so anon-pi init (and persona add/rm) were crossed into the anon account first. init then ran AS anon and, at the image step, tried to sudo -u anon ... from within anon -> "anon is not in the sudoers file. This incident has been reported to the administrator." (the account has no sudo rights).

  init and persona are now dispatched BEFORE the redirect, so they run as the login user (which owns the sudoers rights) and do their own explicit crossings into the account. Launches (anon-pi <project>, --shell) and workspace-scoped verbs (machine, image, container) still redirect as before.

anon-pi@0.29.6

Patch Changes

• c6a4b32: Fix two hardened-reinit bugs: a login-home projects root leaking into the account config (causing mkdir /home/<you>/... EACCES at launch), and prompt defaults not reflecting the account's existing config.

  • init wrote a login-home projects root into the account config. projects: projects ?? current.projects fell back to the login user's stored projects (e.g. /home/<you>/anon) even when you kept the safe anon-tree default, so the hardened launch then tried mkdir /home/<you>/anon/<project> and hit EACCES. There is now a final guard: on a hardened install a login-home projects value is never stored (dropped to the safe anon-tree default).
  • Hardened re-init pre-filled from the wrong config. init runs as the login user and read the login user's ~/.anon-pi/config.json for its defaults, which on a hardened box is just the { hardened: true } marker (or a stale non-hardened config), so the prompts did not reflect what the anon account previously chose. On a hardened install init now reads the account's own config (via a sudo -u anon -i anon-pi __read-config crossing) and uses that for every prompt default.

anon-pi@0.29.5

Patch Changes

• 480f4a7: Fix: a hardened install did not redirect at launch (showed the login user's projects instead of the anon account's).

  The launch redirect decision (isHardenedInstall) runs as the LOGIN USER, before crossing, so it reads the login user's ~/.anon-pi/config.json. But a hardened init writes the whole workspace (including hardened: true) into the anon account's mode-700 home, and nothing into the login user's home. So the login user's config had no hardened flag (or a stale non-hardened one from an earlier init), the redirect never fired, and anon-pi ran as you, reading your login-user projects.

  A hardened init now also writes a minimal login-side marker ({ "hardened": true }) into the login user's ~/.anon-pi/config.json, so every future launch redirects into anon. The marker carries nothing sensitive (no proxy/llm/projects, no transcripts); the real workspace config still lives under the account and is read after the crossing.

  Note: on an existing box that hardened before this fix, re-run anon-pi init once to write the marker.

anon-pi@0.29.4

Patch Changes

• 3a9628f: init / persona add: explain the sudo prompt before crossing into the account.

  On a hardened install, some steps run AS the anon (or anon-<name>) account via sudo -u <account> -i anon-pi ..., which triggers a [sudo] password for <you> prompt. During onboarding this appeared with no explanation (e.g. right after choosing an image, the exists-check crosses to the account). anon-pi now prints a short heads-up before each such crossing: "Crossing into <account> to (sudo may ask for YOUR password)...", so the prompt is never a surprise. Covers the image exists-check + build, and the mode-700 workspace write for both init and persona add. The day-to-day launch redirect is left quiet (a per-launch line would be noise).

anon-pi@0.29.3

Patch Changes

• 1b1a6c4: Fix hardening falsely rejecting a correctly system-installed anon-pi (Volta users).

  Two detection bugs made hardening refuse even after sudo npm install -g anon-pi:

  • It resolved the binary via the login user's PATH, where a per-user Node manager (Volta/nvm) prepends its own dir, so command -v anon-pi returned the per-user shim (e.g. ~/.volta/bin/volta-shim) instead of the system /usr/local/bin/anon-pi. anon-pi now resolves on a SANITIZED PATH with the per-user Node-manager dirs (.volta, .nvm, ...) removed, so a shim never wins over a system install while system dirs (and any other entry) survive; it finds /usr/local/bin/anon-pi even while Volta is still present. It also no longer realpaths the result, keeping the stable /usr/local/bin/anon-pi symlink so the sudoers rule survives version bumps.
  • It rejected a .js path as non-executable. A system npm-global bin is a symlink to a root-owned, world-executable dist/cli.js with #!/usr/bin/env node, which the account runs fine. The non-executable-js reason is removed; the load-bearing disqualifiers stay (under the login home, or a version-manager shim).

  The anon-pi-binary step is now resumable too: install anon-pi system-wide and press Enter to re-check (it finds the system one immediately), instead of aborting init.

anon-pi@0.29.2

Patch Changes

• 1871d66: init: clearer system-wide-anon-pi guidance when hardening is refused for a per-user (Volta/nvm) install.

  The anon-pi-binary remediation now leads with "Because you chose the HARDENED deployment ...", so it is obvious why the requirement applies, and gives a concrete, numbered fix: install Node.js system-wide (noting that a per-user manager like Volta/nvm keeps precedence on your login shell, so a system Node does not disturb your normal workflow), then sudo npm install -g anon-pi (which lands on a shared PATH the account can run), then remove the per-user anon-pi (e.g. volta uninstall anon-pi) so the login user and the account never run two different versions.

anon-pi@0.29.1

Patch Changes

• 83ce0f7: init: surface the system-wide-anon-pi requirement as its own step, not a root command.

  When the only thing blocking hardening was the anon-pi-binary check (e.g. anon-pi is a per-user Volta shim), init still printed the "Root commands to paste (become root FIRST)" block, "Run the commands above in a root shell", and a re-check prompt, even though the only line in that block was sudo -i (the sudoers step was a SKIPPED comment) and no root command could fix it. Installing anon-pi system-wide is a login-user action, and a re-check in the same init session can't help (the running process is still the unsuitable binary).

  The anon-pi-binary requirement is now handled as its own step, before the root-commands flow: init prints a dedicated "anon-pi must be installed system-wide first" message with the install/remove guidance and asks you to reinstall and re-run init (or skip to install non-hardened), rather than telling you to paste commands in a root shell. The Tier-2 root-commands block is only shown when the binary is suitable, so it always contains real commands.