@prohost/cli 0.15.0 → 0.16.1

package/CHANGELOG.md

@@ -6,6 +6,92 @@ builds via `prepack`, runs the suite, publishes, and tags `cli-v<version>`.
 
 ## Unreleased
 
+## 0.16.1
+
+Review follow-ups to `prohost host` that landed on its branch after #22455 merged:
+
+- **Windows dedicated install:** the service home is `C:\ProgramData\Prohost\homes\<account>`, made in
+  one step with administrators-only access, given the computer credential (`wx`), and only then
+  opened to the account — the account can never swap a path in it while an administrator writes
+  there. An existing home is never written into. `--service-home` is refused on Windows (only that folder can
+  be prepared safely), and an install over a 0.16.0 Windows dedicated service (its home was in the
+  account's profile, under another task name) stops and says how to remove it and carry its
+  computer over (`--from-home`), rather than leaving two services on one key.
+- **Claude token scoping:** an adopted Claude harness's sign-in checks add the dedicated install's
+  Claude token only when they run its own Claude binary; the account snapshot's Codex checks never
+  see it.
+- **Muted threads:** an answer dropped because the thread is muted (`409 ai_muted`) — the final one
+  or an early one, Claude or Codex — makes the run forget the conversation's session, so after
+  unmuting nothing resumes from a turn nobody saw.
+
+## 0.16.0
+
+- **`prohost host` — one service per computer, many employees.** A computer is added once
+  (`host pair`: device code, or `--token` for the desktop app's self-add; `--name`,
+  `--expect-account`, `$PROHOST_PAIR_RESULT_FILE`) and serves every AI employee placed on it on
+  one stream authenticated as the computer (`$PROHOST_HOME/host/computer.json`, 0600).
+  - Runs are claimed only when a slot is free (`POST /v1/computers/{id}/runs/{run_id}/claim`,
+    exactly once; `409` → skipped) and executed like `agent run` runs, as the employee with the
+    run's own token (heartbeat, tool events, reply, a per-run MCP config, completion with
+    `peak_mem_mb` / `login_moved`). The claim's skills are written into the employee's workspace
+    (`.claude/skills/<key>/`; `.codex/skills/<key>/` plus an `AGENTS.md` list). A run claimed
+    before a restart is reported, never re-run. The ledger is keyed by employee and conversation.
+  - Run order: someone waiting first, then turns between employees, then oldest; conversations
+    take turns; per-employee `max_concurrent` and `keep_one_ready`; terminal sessions never wait
+    and count against capacity.
+  - Capacity recommended from memory, cores and workload (max(8 GB, 25 %) reserve, ~1.5 GB chat /
+    ~4 GB coding, ≤ half the cores, 1–16), configured in ProhostAI. Holds new work when paused,
+    under critical memory pressure or on battery (each configurable), with `hold_started` /
+    `hold_ended` events. Each run's peak memory is sampled from its process tree.
+  - `POST /v1/computers/{id}/status` every 30 s and on change (host stats, slots, AI logins with
+    plan and quota windows — never the email — running work, capabilities, `recommended_capacity`,
+    `dedicated`); the answer is the computer's config.
+  - Opt-in sharing between AI logins of the same kind: a conversation sticks to its login; when
+    that login rests, its Claude session (`projects/<project>/<id>.jsonl`) or Codex rollout
+    (including a WSL `CODEX_HOME`) is copied to another login and the run resumes with an
+    "interrupted" note (`login_resting`, `login_moved`); otherwise the run waits for the reset.
+    Claude Code and Codex are never mixed.
+  - Terminal sessions (Code threads) are hosted by the same service with the computer credential.
+  - `host status --json`, `host logins --json` (plan and the local-only `email_local`),
+    `host pause` / `resume`, `$PROHOST_HOME/host/activity.json`.
+  - `host install [--dedicated --service-user <name>]` / `uninstall`: launchd (user agent / system
+    daemon with `UserName`), systemd (user / system unit with `User=`), Windows Task Scheduler (at
+    logon / at boot as the service user via S4U). Stopping or an update drains: no new work, runs
+    going finish, then it exits (75 after an update) for the service manager to restart it.
+  - `host migrate` adopts existing agent homes (sessions carried over; served with their own
+    credential, in their own `--workdir`, until placed on the computer) and the desktop app's
+    terminal-hosting home (`ai.prohost.desktop[.dev].code-host`), stops the old launchd agents it
+    adopted (`--keep-services`, `--dry-run`, `--json`), and keeps earlier adoptions on a re-run.
+    It refuses while the host service runs (the service owns the ledger).
+  - One `host run` per home (`host/service.lock`); each employee's runs share one session ledger.
+  - For the desktop app: `host install|uninstall --label <id>` (default derived from the home);
+    services run the CLI with the executable that launched it, keeping `ELECTRON_RUN_AS_NODE=1`
+    and the launching `PATH` under Electron; re-running install leaves a right service alone.
+    `host migrate --from <home>` (repeatable, read-only) and computer adoption through an agent
+    key (`/v1/computers/pairing/adopt`). `host logins add --runtime …`, `host unpair`.
+    `host status --json` always exits 0 and adds `hardware`, `events` (24 h, stable ids) and
+    `service`. `host pause` also stops new terminal sessions (open ones carry on).
+  - Dedicated: creates the service account (macOS / Linux), copies this home's `computer.json`,
+    installs `--claude-token-file` for `CLAUDE_CODE_OAUTH_TOKEN`, logs to the journal /
+    root-owned `/Library/Logs/Prohost` / ACL'd ProgramData (never under the service user's
+    home), and publishes its state for the logged-in user's `host status` / `host pause`.
+  - `host pair` names the approved workspace and, in a terminal without a matching
+    `--expect-account`, asks before saving; a declined or mismatched key is revoked.
+  - Terminal sessions use the computer key on `/v1/code-hosts/control`, falling back to the
+    adopted agent key on a server that refuses it.
+  - The send rule: replies carry the agent's `confidence` / `reply_class` (a trailer line it is
+    asked for, stripped before sending — a missing or malformed one sends neither, never a
+    default); a reply held as a suggestion, or refused because the thread is muted (`ai_muted`),
+    is handled, not failed.
+- `claude auth status --json`'s `subscriptionType` is now read (the email only for local display).
+- Host stats on Linux (`/proc/meminfo`, `/proc/pressure/memory`, `/sys/class/power_supply`) and
+  Windows (`typeperf` counters, `Win32_Battery`), beside macOS.
+- `prohost agent run` and every other command are unchanged.
+- **`agent install-daemon` re-install no longer fails while the old agent drains.** After
+  `bootout` it waits (bounded at 90 s) for `launchctl print` to say the old job has left launchd
+  before `bootstrap`; bootstrapping while the old agent finished its in-flight run failed with
+  "Input/output error". A bootstrap that still fails says when the old agent had not stopped.
+
 ## 0.15.0
 
 - **Code threads on this Mac: scroll back locally, no flashing, no permission prompts.**

package/README.md

@@ -1,7 +1,11 @@
 # `@prohost/cli`
 
-The [ProhostAI](https://prohost.ai) command-line tool. Three things it does:
+The [ProhostAI](https://prohost.ai) command-line tool. Four things it does:
 
+- **`prohost host`** — add this computer to your workspace once, and it works
+  for every AI employee you place on it: Claude Code or Codex, on the AI logins
+  signed in here, several things at once, plus the terminal sessions you open
+  on it. See [Computers](#computers-prohost-host).
 - **`prohost agent`** — run your own local agent as a ProhostAI teammate. Someone
   @-mentions it in the app, it runs on your machine, and its answer is posted
   back into the conversation.
@@ -41,6 +45,267 @@ The rest of this page is detail on each step.
 
 ---
 
+## Computers: `prohost host`
+
+A computer is added to a workspace once and then serves **every** AI employee
+placed on it — one background service, one connection, many employees, each
+running Claude Code or Codex on the AI logins signed in on this machine. It also
+hosts the terminal sessions people open on it from ProhostAI.
+
+```bash
+npx @prohost/cli host pair        # prints a code; enter it in ProhostAI → AI Employees → Computers
+npx @prohost/cli host install     # keep it running in the background
+npx @prohost/cli host status      # what it is doing
+```
+
+Then pick the computer under **Where it works** when you hire (or edit) an AI
+employee. `prohost agent run` keeps working exactly as before for anything you
+paired that way.
+
+### Commands
+
+| Command | What it does |
+| --- | --- |
+| `host pair [--name <n>] [--expect-account <id>]` | Device-code pairing: prints a code and the page to enter it on, waits for approval, stores the computer credential in `$PROHOST_HOME/host/computer.json` (0600). |
+| `host pair --token <redeem_token>` | Redeems a one-time token from the signed-in desktop app instead (`--token -` reads it from stdin; `$PROHOST_REDEEM_TOKEN` also works). The token is never printed. |
+| `host run [--machine <n>] [--timeout <s>] [--idle-timeout <s>] [--workload coding\|chat]` | The service, in the foreground. |
+| `host install [--label <id>] [--dedicated --service-user <name> [--service-home <dir>] [--claude-token-file <path>]]` / `host uninstall [--label <id>]` | The background service for this OS (below). Safe to re-run: nothing that is already right is touched. |
+| `host unpair` | Remove this computer from its workspace (`DELETE /v1/computers/{id}` with its own key), then delete `computer.json`. Exits 0 only when the server removed it, or had already. |
+| `host status [--json] [--label <id>]` | Online, paused, capacity, what is running, AI logins, hardware, recent events. Always exits 0. |
+| `host logins [--json]` | The AI logins found on this machine, with their plan and (locally only) email. |
+| `host logins add --runtime claude_code\|codex [--label <l>]` | A new AI login in its own config directory (`~/.prohost-accounts`), signed in right here (`claude auth login` / `codex login`). |
+| `host pause` / `host resume` | Take no new work and open no new terminal sessions / take them again. Work already going finishes. |
+| `host migrate [--from <home>]… [--home <dir,…>] [--keep-services] [--dry-run] [--json]` | Adopt existing agent homes and the desktop app's terminal-hosting home, and become a computer through their agent keys (below). |
+
+`--expect-account` works as it does for `agent pair`: a computer approved in any
+other workspace is refused and nothing is stored. `$PROHOST_PAIR_RESULT_FILE`
+gets `{"version": 1, "outcome", "computer_id", "account": {"id", "name"}, "message"}`
+(outcomes: `paired`, `expired`, `token_rejected`, `workspace_unconfirmed`,
+`declined`, `rate_limited`, `unreachable`, `invalid_arguments`, `failed`), written
+0600 and atomically, never holding the code, token or key.
+
+Once approved, pairing prints the workspace it was approved in. In a terminal,
+unless `--expect-account` already vouched for it, it asks "Add this computer to
+<workspace>? [y/N]" before saving anything; no (or a workspace that doesn't match
+`--expect-account`) revokes the new key on the server and saves nothing. A
+program (no terminal) relies on `--expect-account`.
+
+### How a run works on a computer
+
+1. ProhostAI sends `agent.run_requested` on the computer's stream (signed with
+   the pairing's secret; an unsigned frame is refused and never run).
+2. The run waits its turn (below). When a slot is free and its AI login has
+   room, the computer **claims** it (`POST /v1/computers/{id}/runs/{run_id}/claim`).
+   Exactly one computer ever gets a claim; a `409` means another computer took
+   it, and it is skipped.
+3. The claim returns the run, a short-lived **run token** and the employee's
+   **skills**. The skills are written into the employee's workspace —
+   `.claude/skills/<key>/…` for Claude Code; `.codex/skills/<key>/…` plus a
+   list in `AGENTS.md` for Codex — and skills no longer granted are removed.
+4. The run executes exactly like an `agent run` run (same prompt, sessions,
+   tool events, reply, completion) but **as the employee, with the run token**:
+   the heartbeat, tool events, reply, its MCP config (a file of its own,
+   removed afterwards) and its completion all carry that token, never the
+   computer's key. The completion adds the run's `peak_mem_mb` and, if it moved,
+   `login_moved`.
+5. A run claimed but never reported (the service stopped mid-run) is reported
+   failed on the next start, with its own token — it is never run again.
+
+Employees on a computer **skip permission prompts** (Claude
+`--dangerously-skip-permissions`, Codex `--yolo`); message approval rules still
+apply on the server. Each employee has its own home under
+`$PROHOST_HOME/host/employees/<agent_id>/` (its sessions, workspace and
+`extra-mcp.json` if you add one).
+
+### Run order
+
+Someone waiting (a mention, a DM, a customer's message) goes first; then the
+employees take turns (the one with the fewest runs going, then the one that
+started longest ago); then oldest first. Runs in one conversation always take
+turns. Terminal sessions never wait — they count against capacity, so they
+shrink what the employees get. Each employee's **Up to N** caps its own runs,
+and **Keep one ready** keeps a slot free for it while it has nothing running.
+
+### Capacity and holds
+
+Capacity is how many things the computer works on at once. It is set in
+ProhostAI; until it is, the recommendation is used: memory after a reserve of
+max(8 GB, 25 %), divided by ~1.5 GB per chat run or ~4 GB per coding run
+(`--workload`), at most half the cores, between 1 and 16.
+
+New work is **held** (work going is never stopped) while the computer is paused
+(`host pause`, or in ProhostAI), under critical memory pressure, or on battery —
+each hold can be switched off in ProhostAI. Holds are reported as they start and
+end. The service reports every 30 seconds and on any change: CPU, memory, memory
+pressure (macOS `kern.memorystatus_vm_pressure_level`; Linux
+`/proc/pressure/memory`; Windows performance counters through `typeperf`),
+battery, slots, AI logins and what is running with each run's peak memory
+(the agent process and everything it started, sampled every 5 s).
+
+### AI logins and sharing between them
+
+A login is a Claude Code or Codex sign-in: `~/.claude`, `~/.codex`, and every
+account in `~/.prohost-accounts` (`prohost agent account add`). The plan comes
+from `claude auth status --json` (`subscriptionType`, e.g. "Claude Max") or
+Codex's rate-limit read ("ChatGPT Pro"). The email in `claude auth status`
+is shown by `host logins` on this machine only; it is never sent.
+
+A conversation sticks to the login holding its session. New conversations go to
+the login with the most room. When a login hits its usage limit it **rests**
+until its reset, and ProhostAI is told (`login_resting`). Then:
+
+- **Sharing on** (per computer, per kind, in ProhostAI): the conversation's
+  session file is copied to another login **of the same kind** — Claude Code's
+  `projects/<project>/<session>.jsonl` under the other `CLAUDE_CONFIG_DIR`, or
+  Codex's rollout under the other `CODEX_HOME` (a WSL `CODEX_HOME` given as
+  `wsl://<distro>/<path>` is reached through `\\wsl.localhost\<distro>\…`) —
+  and the run resumes there, told it was interrupted and to check what is
+  already done (`login_moved`). Claude Code and Codex are never mixed.
+- **Sharing off, or no other login has room**: a run going is reported failed
+  with the limit and its reset time, so ProhostAI runs it again after the reset;
+  runs not started yet wait for the earliest reset.
+
+### The background service
+
+| | `host install` | `host install --dedicated --service-user <name>` |
+| --- | --- | --- |
+| macOS | LaunchAgent `<label>` (while you are logged in) | LaunchDaemon `/Library/LaunchDaemons/<label>.plist` with `UserName` |
+| Linux | systemd user unit (`loginctl enable-linger` to outlive your session) | system unit in `/etc/systemd/system` with `User=` |
+| Windows | Task Scheduler task at logon | the same task at boot, running as the service user (S4U: no password stored) |
+
+The label is `ai.prohost.host` for `~/.prohost` (unit `prohost-host.service`,
+task `\ProhostAI\Host`) and one derived from `$PROHOST_HOME` for any other home,
+so two homes never replace each other's service; `--label` sets it (the desktop
+app passes `ai.prohost.desktop.host` / `ai.prohost.desktop.dev.host`).
+
+Dedicated mode keeps working when no one is logged in; install it as root /
+from an administrator prompt. It:
+
+- creates the service account if it doesn't exist (macOS: a hidden user, ids
+  401–499; Linux: a system user; on Windows the account must already exist —
+  creating one there means choosing a password policy);
+- uses that account's `~/.prohost` (`--service-home` sets another), copies your
+  `computer.json` into it if it has none (pair as yourself, then install; under
+  sudo "yours" is `$SUDO_USER`'s `~/.prohost`, or `--from-home <dir>`), and
+  installs `--claude-token-file` (a `claude setup-token` token) there for every
+  Claude run (adopted Claude agents too) and Claude login check as
+  `CLAUDE_CODE_OAUTH_TOKEN` (never to Codex, never on a command line, so not to
+  terminal sessions either: they would carry it in tmux's arguments) — read
+  once, never printed, re-read each time so installing a new one needs no
+  restart. Everything in the
+  account's home is written as the account (`sudo -u` / `runuser`), never by
+  root through a path the account controls (a `--service-home` the account
+  can't create is made by root only under a root-owned folder, then handed
+  over). On Windows the ProgramData folders are made in one step or, if they
+  were there, kept only when Administrators / SYSTEM own them; each is taken over
+  top-down (owner Administrators, `/reset`, exactly our grants), checked again
+  afterwards (owner, no junction, no other principal), and the token is always a
+  new file (`wx`) in
+  `C:\ProgramData\Prohost\secrets\<label>` (the account may only read it), and
+  the account's service home is `C:\ProgramData\Prohost\homes\<account>`:
+  made in one step with administrators-only access, given the credential, and
+  only then opened to the account (an existing one is never written into). If your own (personal) service runs on the same computer
+  key, install says so and how to remove it;
+- logs where the service account can't redirect it: the journal on Linux,
+  `/Library/Logs/Prohost/<label>.log` (in a root-owned folder) on macOS,
+  `C:\ProgramData\Prohost\Logs` (ACL: SYSTEM, administrators, the service
+  account) on Windows;
+- publishes its state for anyone logged in on the computer, without login
+  emails, in a root-owned `/Library/Application Support/Prohost/hosts/<label>`,
+  `/var/lib/prohost/hosts/<label>` or `C:\ProgramData\Prohost\hosts\<label>`: the service owns only
+  `state.json`, `activity.json` and `events.json` there, and `control.json` is
+  the pause switch anyone on the computer may flip. `host status` and
+  `host pause` run as the logged-in user find it there, and
+  `sudo prohost host uninstall` finds the service by it (install prints the exact
+  command with its `--label`).
+
+On Windows it is a boot-start task rather than a Windows service, because Node
+cannot answer the Service Control Manager without a native wrapper.
+
+Every variant runs `<executable> <cli> host run` with the `PATH` it was installed
+from: Node, or — under the desktop app — the app's Electron binary, with
+`ELECTRON_RUN_AS_NODE=1` (and `PROHOST_CLI_RUN=1`) kept in the service's
+environment so it runs the CLI rather than opening the app. Personal services
+log to `$PROHOST_HOME/host/host.log`. Re-running `host install` changes nothing
+that is already right (the desktop app runs it after every update); a changed
+definition is loaded after the old service drains. Only one `host run`
+runs per `PROHOST_HOME` (`host/service.lock`); a second one refuses to start.
+The systemd unit uses `KillMode=mixed`, so a stop reaches the host first and its
+runs can finish. Re-installing on macOS waits for the previous service to finish
+draining (up to its 10-minute stop timeout) before loading the new one. A dedicated install hands the service user's `PROHOST_HOME` to
+that user (`chown`); on Windows it checks for an elevated prompt first. **Updates drain:**
+when a newer CLI is installed over the running one (or the service is told to
+stop), it takes no new work, lets the runs going finish, then exits (code 75
+after an update) for the service manager to start the new one. A second
+Ctrl-C (or signal) stops the runs going too.
+
+### Migrating an existing setup: `host migrate`
+
+`host migrate` brings agents you already run under the host service without
+pairing anything again. When this home has no computer yet, it becomes one
+through an adopted home's agent key (`POST /v1/computers/pairing/adopt`): the
+pairing's creator owns it, no code to enter. `--from <home>` (repeatable) adopts
+only those homes — nothing is discovered, nothing is stopped, the homes are only
+read — which is how the desktop app hands over its own; exit 0 means adopted, or
+nothing to adopt.
+
+- **Agent homes** — every home a launchd agent `ai.prohost.agent.*` runs (its
+  `--exec`, `--workdir`, `--concurrency`, `--repos`, timeouts and `--safe-tools`
+  are read from the plist), `$PROHOST_HOME`, and each `--home` (the desktop
+  app passes the homes of the agents it supervises). Their
+  conversation sessions are copied to the employee's host home. Until
+  ProhostAI places that employee on this computer, `host run` keeps serving it
+  with **its own credential**, as `agent run` did; once it is placed, the
+  computer serves it and the old connection is stopped.
+- **The terminal-hosting home** — a `--host-only` home (including the desktop
+  app's `ai.prohost.desktop[.dev].code-host` agent), or one with Code-thread
+  hosting on. The service hosts terminal sessions from it, so open terminals,
+  opened folders and the remote switches carry over.
+- **Old launchd agents** it adopted are stopped and removed (`--keep-services`
+  keeps them; then stop them yourself, or each employee is answered twice).
+
+It cannot adopt: a systemd unit or Windows task written by hand from
+`agent install-daemon` (pass `--home` and stop the unit yourself); an agent the
+desktop app supervises (the app stops it); an `--exec` that is neither Claude
+Code nor Codex (it keeps running on its own credential and is never served as
+the computer); a home whose `agent.json` is missing, unreadable or revoked; the
+sessions of a home that ran in a custom `--workdir`, once the computer serves it
+(Claude Code files sessions by directory, and the host never runs an employee in
+a checkout — those conversations start fresh; until then its own connection
+keeps running in that `--workdir`); `prohost listen` and `prohost usage`
+daemons. Running `host migrate` again keeps what it adopted before, including
+settings read from plists it has since removed. It refuses while the host
+service is running (the service owns the run ledger): stop it, migrate, then
+start it again. `--dry-run` shows what it would do; `--json` prints the report.
+
+### For the desktop app
+
+- `host status --json` (always exits 0) →
+  `{paired, computer: {id, name, account: {id, name}}, online, paused, slots: {total, busy, held, held_reason}, running: [{run_id, agent: {id, name, avatar_url}, title, started_at, kind}], logins: [{account_key, label, runtime, subscription_type, plan_label, email_local, auth_state, windows}], capacity, recommended_capacity, hardware: {memory_gb, cpu_cores, os, chip}, events: [{id, kind, at, …}], service: {running, pid, adopted, dedicated, activity_file?}, version}`.
+  `online` is false when the service has not written its state for 2 minutes.
+  `events` are the last 24 h of what the service sent (`login_resting`,
+  `login_moved`, `hold_started`, `hold_ended`, with the `/events` fields plus
+  `computer_id` / `computer_name`), newest last, each with a stable `id`.
+  `service` says whether a service runs for this home (`host/service.lock`), how
+  many homes it adopted, and — run as the logged-in user on a dedicated computer —
+  that it is the dedicated service (`activity_file` is then its shared copy).
+- `host logins --json` → `{logins: [...same shape as status...]}`.
+- `$PROHOST_HOME/host/activity.json` → `{v: 1, busy, running: [...as in status...], updatedAt}`.
+- `$PROHOST_HOME/host/state.json` is the service's own state (0600); read
+  `status --json` rather than this file.
+- `host pause` / `resume` write `$PROHOST_HOME/host/control.json` (and a
+  dedicated service's shared `control.json`); the running service picks it up
+  within 2 seconds. Paused, it also starts no new terminal session (the start
+  is reported failed, "this computer is paused") and lets no new viewer dial
+  in; terminals already open, their replies and approvals carry on.
+- `prohost --help` names what this build can do: `ELECTRON_RUN_AS_NODE`
+  (services written for the desktop app), `--claude-token-file`, `host unpair`.
+- Terminal sessions authenticate to `/v1/code-hosts/control` with the computer
+  key; a server from before computer keys (`not_paired`) is asked again with the
+  adopted terminal-hosting home's agent key. A revoked or invalid key never
+  falls back.
+
+
 ## Bring your own agent
 
 Any agent that reads a prompt on stdin and writes its answer to stdout works —

package/dist/agent/accounts.d.ts

@@ -155,6 +155,16 @@ export interface AuthCheck {
     state: AuthState;
     /** What the login itself says it bills to, when it says. */
     billing?: AccountBilling;
+    /**
+     * Claude Code's `subscriptionType` (`max`, `pro`, …), lowercased, when the
+     * login says. Safe to send: it names a plan, not a person.
+     */
+    subscriptionType?: string;
+    /**
+     * The login's email, only when the caller asked for it (`includeEmail`).
+     * Local display only (`prohost host logins`): it is never sent anywhere.
+     */
+    email?: string;
 }
 /** Runs one short command with extra env; resolves exit code and stdout. Never rejects. */
 export type CommandRunner = (command: string, args: string[], env: NodeJS.ProcessEnv) => Promise<{
@@ -174,6 +184,7 @@ export declare const defaultCommandRunner: CommandRunner;
 export declare function checkAuth(record: AccountRecord, options?: {
     binary?: string;
     run?: CommandRunner;
+    includeEmail?: boolean;
 }): Promise<AuthCheck>;
 /**
  * Poll until the operator has finished signing in, or until the deadline.

package/dist/agent/accounts.js

@@ -520,7 +520,13 @@ export async function checkAuth(record, options = {}) {
         let parsed;
         try {
             const json = JSON.parse(stdout.trim());
-            parsed = { loggedIn: json.loggedIn, authMethod: json.authMethod };
+            // The org is never read; the email only when the caller shows it locally.
+            parsed = {
+                loggedIn: json.loggedIn,
+                authMethod: json.authMethod,
+                subscriptionType: json.subscriptionType,
+                email: options.includeEmail ? json.email : undefined,
+            };
         }
         catch {
             return { state: 'unknown' };
@@ -530,9 +536,14 @@ export async function checkAuth(record, options = {}) {
         if (parsed.loggedIn !== true)
             return { state: 'unknown' };
         const method = typeof parsed.authMethod === 'string' ? parsed.authMethod : '';
+        const plan = typeof parsed.subscriptionType === 'string' && /^[A-Za-z0-9_-]{1,32}$/.test(parsed.subscriptionType)
+            ? parsed.subscriptionType.toLowerCase()
+            : undefined;
         return {
             state: 'ok',
             billing: method === 'claude.ai' ? 'subscription' : method ? 'api_key' : undefined,
+            ...(plan ? { subscriptionType: plan } : {}),
+            ...(typeof parsed.email === 'string' && parsed.email ? { email: parsed.email } : {}),
         };
     }
     const { code, stdout } = await run(options.binary ?? 'codex', ['login', 'status'], env);

package/dist/agent/api.d.ts

@@ -20,9 +20,21 @@ export interface ApiOptions {
      * {@link SEND_TIMEOUT_MS} for the reply and the completion.
      */
     timeoutMs?: number;
+    /**
+     * Fields a completion carries beside the terminal state, read when it is
+     * sent. `prohost host` adds the run's peak memory and any login move here;
+     * `agent run` sets none, so its completions are unchanged.
+     */
+    completionExtra?: () => Record<string, unknown>;
 }
 export interface ApiResult {
     ok: boolean;
+    /**
+     * A send the server answered without sending (still `ok`: the run is done):
+     * saved as a draft for the team (`suggestion`), or dropped because the thread
+     * is muted for AI (`muted`).
+     */
+    withheld?: 'suggestion' | 'muted';
     /** HTTP status, or ``0`` when no response arrived at all — see ``failure``. */
     status: number;
     error?: string;

package/dist/agent/api.js

@@ -191,6 +191,11 @@ export async function completeRun(options, path, outcome, model) {
     }
     if (model)
         body.model = model.slice(0, MAX_MODEL_CHARS);
+    // Never over the fields above: the terminal state is what the call is for.
+    for (const [key, value] of Object.entries(options.completionExtra?.() ?? {})) {
+        if (!(key in body) && value !== undefined)
+            body[key] = value;
+    }
     const result = await postJson(options, path, body, undefined, false, SEND_TIMEOUT_MS);
     if (result.status === 409)
         return { ...result, ok: true };

package/dist/agent/claude.d.ts

@@ -314,6 +314,12 @@ export interface McpConfigOptions {
      */
     extraServers?: Record<string, Record<string, unknown>>;
     env?: NodeJS.ProcessEnv;
+    /**
+     * Write here instead of `$PROHOST_HOME/mcp.json`. `prohost host` gives each
+     * run its own file: the key in it is that run's token, and two runs of one
+     * employee must never read each other's.
+     */
+    file?: string;
 }
 /**
  * The config object handed to `--mcp-config`.

package/dist/agent/claude.js

@@ -857,8 +857,8 @@ export function buildMcpConfig(options) {
  */
 export function writeMcpConfig(options) {
     const env = options.env ?? process.env;
-    const dir = prohostHome(env);
-    const file = mcpConfigPath(env);
+    const file = options.file ?? mcpConfigPath(env);
+    const dir = path.dirname(file);
     mkdirSync(dir, { recursive: true, mode: 0o700 });
     chmodSync(dir, 0o700);
     // Written beside the target and renamed over it. Every run rewrites this

package/dist/agent/daemon.d.ts

@@ -30,6 +30,10 @@ export interface DaemonSpec {
     logPath: string;
     /** Extra environment launchd must set — launchd inherits almost nothing. */
     env?: Record<string, string>;
+    /** A system daemon only: the user it runs as (`UserName`). */
+    userName?: string;
+    /** Seconds launchd waits after SIGTERM before SIGKILL (`ExitTimeOut`). */
+    exitTimeoutSeconds?: number;
 }
 /**
  * Label for the daemon serving one `$PROHOST_HOME`.
@@ -114,17 +118,46 @@ type Runner = (command: string, args: string[]) => {
     status: number | null;
     stderr: string;
 };
+/**
+ * How long a re-install waits for the old job to leave launchd after its
+ * `bootout`. Bootout only sends SIGTERM: `agent run` then finishes its
+ * in-flight runs ("Finishing the in-flight run…"), and launchd keeps the label
+ * until the process exits — SIGKILL after the job's `ExitTimeOut`, 20 s by
+ * default (this plist sets none). A `bootstrap` before then fails with
+ * "Input/output error". 90 s covers that with room for a busy Mac; the
+ * desktop app waits the same way (`desktop/src/main/code-host/launchd.ts`).
+ */
+export declare const OLD_JOB_EXIT_TIMEOUT_MS = 90000;
+/**
+ * Ask `launchctl print` until the job is gone (any exit but 0) or the bound
+ * passes: whether it went. No answer (`status` null) is never "gone". Says
+ * once that it is waiting, and boots the job out once more half-way through
+ * (a first bootout that failed outright rather than drained).
+ */
+export declare function waitUntilUnloaded(run: Runner, target: string, clock: {
+    sleep: (ms: number) => void;
+    now: () => number;
+    timeoutMs: number;
+    onWaiting: (line: string) => void;
+}): boolean;
 /**
  * Write the plist and hand it to launchd.
  *
  * `bootout` first, ignoring its result: bootstrapping a label that is already
  * loaded fails outright, so a plain re-install of an agent whose `--exec`
  * changed would otherwise keep running the old command and report success.
+ * Then wait (bounded) until launchd has let the old job go: it drains on
+ * SIGTERM, and bootstrapping while it does fails.
  */
 export declare function installLaunchdDaemon(spec: DaemonSpec, options?: {
     home?: string;
     uid?: number;
     run?: Runner;
+    sleep?: (ms: number) => void;
+    now?: () => number;
+    exitTimeoutMs?: number;
+    /** Progress while the old agent stops (default: stderr). */
+    onWaiting?: (line: string) => void;
 }): InstallResult;
 /**
  * Unload the daemon and delete its plist. Missing pieces are not an error.

package/dist/agent/daemon.js

@@ -116,6 +116,11 @@ export function buildLaunchdPlist(spec) {
         '  <key>StandardErrorPath</key>',
         `  <string>${xmlEscape(spec.logPath)}</string>`,
     ];
+    if (spec.userName)
+        lines.push('  <key>UserName</key>', `  <string>${xmlEscape(spec.userName)}</string>`);
+    if (spec.exitTimeoutSeconds !== undefined) {
+        lines.push('  <key>ExitTimeOut</key>', `  <integer>${Math.max(0, Math.floor(spec.exitTimeoutSeconds))}</integer>`);
+    }
     if (spec.env && Object.keys(spec.env).length > 0) {
         lines.push('  <key>EnvironmentVariables</key>', '  <dict>', ...stringEntries(spec.env, '    '), '  </dict>');
     }
@@ -205,12 +210,56 @@ const defaultRunner = (command, args) => {
     const result = spawnSync(command, args, { encoding: 'utf8' });
     return { status: result.status, stderr: result.stderr ?? '' };
 };
+/**
+ * How long a re-install waits for the old job to leave launchd after its
+ * `bootout`. Bootout only sends SIGTERM: `agent run` then finishes its
+ * in-flight runs ("Finishing the in-flight run…"), and launchd keeps the label
+ * until the process exits — SIGKILL after the job's `ExitTimeOut`, 20 s by
+ * default (this plist sets none). A `bootstrap` before then fails with
+ * "Input/output error". 90 s covers that with room for a busy Mac; the
+ * desktop app waits the same way (`desktop/src/main/code-host/launchd.ts`).
+ */
+export const OLD_JOB_EXIT_TIMEOUT_MS = 90_000;
+const OLD_JOB_POLL_MS = 500;
+const sleepSync = (ms) => {
+    Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, ms);
+};
+/**
+ * Ask `launchctl print` until the job is gone (any exit but 0) or the bound
+ * passes: whether it went. No answer (`status` null) is never "gone". Says
+ * once that it is waiting, and boots the job out once more half-way through
+ * (a first bootout that failed outright rather than drained).
+ */
+export function waitUntilUnloaded(run, target, clock) {
+    const startedAt = clock.now();
+    const deadline = startedAt + clock.timeoutMs;
+    let said = false;
+    let resent = false;
+    for (;;) {
+        const printed = run('launchctl', ['print', target]);
+        if (printed.status !== null && printed.status !== 0)
+            return true;
+        if (clock.now() >= deadline)
+            return false;
+        if (!said) {
+            said = true;
+            clock.onWaiting('Waiting for the previous agent to stop (it finishes what it was doing first)…');
+        }
+        if (!resent && clock.now() - startedAt >= clock.timeoutMs / 2) {
+            resent = true;
+            run('launchctl', ['bootout', target]);
+        }
+        clock.sleep(OLD_JOB_POLL_MS);
+    }
+}
 /**
  * Write the plist and hand it to launchd.
  *
  * `bootout` first, ignoring its result: bootstrapping a label that is already
  * loaded fails outright, so a plain re-install of an agent whose `--exec`
  * changed would otherwise keep running the old command and report success.
+ * Then wait (bounded) until launchd has let the old job go: it drains on
+ * SIGTERM, and bootstrapping while it does fails.
  */
 export function installLaunchdDaemon(spec, options = {}) {
     const home = options.home ?? os.homedir();
@@ -227,6 +276,12 @@ export function installLaunchdDaemon(spec, options = {}) {
     writeFileSync(plistPath, buildLaunchdPlist(spec), { mode: 0o600 });
     chmodSync(plistPath, 0o600);
     run('launchctl', ['bootout', `${domain}/${spec.label}`]);
+    const oldGone = waitUntilUnloaded(run, `${domain}/${spec.label}`, {
+        sleep: options.sleep ?? sleepSync,
+        now: options.now ?? Date.now,
+        timeoutMs: options.exitTimeoutMs ?? OLD_JOB_EXIT_TIMEOUT_MS,
+        onWaiting: options.onWaiting ?? ((line) => process.stderr.write(`${line}\n`)),
+    });
     const bootstrap = run('launchctl', ['bootstrap', domain, plistPath]);
     if (bootstrap.status !== 0) {
         return {
@@ -234,6 +289,7 @@ export function installLaunchdDaemon(spec, options = {}) {
             plistPath,
             message: `Wrote ${plistPath}, but \`launchctl bootstrap ${domain}\` failed` +
                 `${bootstrap.stderr.trim() ? `: ${bootstrap.stderr.trim()}` : '.'}\n` +
+                (oldGone ? '' : `  The previous agent was still stopping after ${Math.round((options.exitTimeoutMs ?? OLD_JOB_EXIT_TIMEOUT_MS) / 1000)}s.\n`) +
                 `Load it by hand with: launchctl bootstrap ${domain} ${plistPath}`,
         };
     }