sessionpipe 0.9.0 → 0.11.0

package/README.md

@@ -92,7 +92,13 @@ Permission prompts can be answered from the receiver too: while the terminal sho
 its prompt, the PermissionRequest hook waits for your signed answer, and whichever
 comes first wins. Nothing is ever auto-allowed. Safe mode (the default) runs headless
 turns with `--permission-mode dontAsk`, so nothing that needs approval runs while
-you're away.
+you're away. Auto mode runs them with `--permission-mode auto`; where Claude Code's
+settings turn auto mode off (`permissions.disableAutoMode`), Claude Code runs them in
+its default mode instead, which refuses whatever needs approval. Inherit mode
+(`sessionpipe control mode inherit`, chosen only at the machine) passes no permission
+flag, so each turn starts in the mode Claude Code picks by itself there, its
+settings' `permissions.defaultMode`: messaged sessions run the way your own do,
+`bypassPermissions` included if that is what you set.
 
 Codex and Antigravity sessions are reached headlessly too, when `codex` or `agy` is
 installed (the daemon looks on PATH, beside its own Node, in `~/.local/bin`, or where
@@ -101,7 +107,9 @@ installed (the daemon looks on PATH, beside its own Node, in `~/.local/bin`, or
 message is `codex exec resume <thread>` or `agy --conversation <id>`. Safe mode runs
 Codex in its `workspace-write` sandbox and agy with no permission flag (it denies, and
 the reply lists, what it wasn't allowed to do); auto mode passes `--approve-for-me` /
-`--mode accept-edits`. The bypass flags are never passed. Both CLIs pick a new
+`--mode accept-edits`; inherit mode passes no flag, so Codex follows the
+`approval_policy` and `sandbox_mode` in your `config.toml`. The bypass flags are never
+passed. Both CLIs pick a new
 session's id themselves, so the daemon keeps the one your start named: it records the
 pair in `~/.local/state/sessionpipe/control/aliases.json`, and your receiver keeps
 seeing one session under one id. A message to a Codex session someone has open (its
@@ -109,6 +117,67 @@ rollout written in the last 90 seconds) is acked `unsupported` rather than resum
 Before a Codex run the daemon checks `codex login status` (or `CODEX_API_KEY`) and says
 `codex login --device-auth` if it isn't signed in.
 
+Any other agent that speaks the [Agent Client Protocol](https://agentclientprotocol.com)
+is reached the same way: Gemini CLI, OpenCode, goose, Copilot CLI, Cursor, Droid, Devin,
+Kilo, Qwen Code, Cline and the rest of the ACP registry ([the list, with each one's
+launch line](../../spec/ADAPTERS.md#agents-driven-through-acp-control-only)). The daemon
+runs the agent's own CLI (`gemini --acp`, `opencode acp`, …) when it is installed, on
+PATH or where `SESSIONPIPE_ACP_<HARNESS>` points (`SESSIONPIPE_ACP_GEMINI_CLI`), and
+never downloads one. It is the agent's client: a start opens a session in your folder,
+the reply streams back as the agent writes it, and the process stays up so the next
+message lands in it with no cold start (`api` mode); `cancel` works there too. An agent
+idle for ten minutes is closed, and a later message reopens the session where the agent
+supports `session/load`. Safe mode answers every permission the agent asks with a
+refusal, listed in the reply; auto mode allows. An agent that never asks (OpenCode, by
+its own settings) runs its tools as it would at your terminal. Signing in is yours to do
+at the terminal: an agent that wants it says so in the reply.
+
+## The pool: several Claude accounts, one session that keeps going
+
+Claude Code can't change account mid-session, but its requests can. `sessionpipe pool`
+keeps several Claude accounts behind one loopback listener the control daemon runs on
+this machine; Claude Code is pointed at it through the `env` block of its
+`settings.json` (`ANTHROPIC_BASE_URL`, `ANTHROPIC_AUTH_TOKEN`, and the one flag that
+keeps its first-party features on). Each request goes to the first account in your order
+that has room, a session stays on its account while that account has room, and when the
+account's 5-hour or weekly window is used up the next request simply goes to the next
+account: the session notices nothing. The numbers each account reports arrive as
+`limits.observed` with `account_id`, so a receiver's usage page shows every account
+([spec](../../spec/CONTROL.md#pool), [what it reads](../../spec/ADAPTERS.md),
+[privacy](../../spec/PRIVACY.md)).
+
+```sh
+sessionpipe pool add --import        # copy every Claude Code login on this machine into the pool
+sessionpipe pool add --login         # sign in to another account: a URL, then paste the code to --code -
+sessionpipe pool on                  # write the env block; installs the daemon's service if it isn't there
+sessionpipe pool                     # the accounts in order, each with its room left and reset times
+sessionpipe pool order <id|email>…   # the complete order; enable | disable | remove | refresh too
+sessionpipe pool off                 # remove exactly what `on` wrote; the accounts stay
+```
+
+Nothing here happens until you run `pool add` or `pool on` yourself: `install` and
+`connect` never touch the pool. The credentials you add live in sessionpipe's own secrets
+store (the keychain where there is one), are sent only to the vendor's own endpoints for
+your own requests, and never appear on an event, in an ack or on the terminal. The
+vendor is called (requests forwarded, idle usage read every five minutes) only while the
+pool is on; `pool add --login` and `pool refresh` at the terminal are the exceptions,
+because you asked. Whether pooling is allowed by each account's plan is yours to check;
+sessionpipe doesn't change any limit.
+
+New Claude Code sessions use the pool from the moment `pool on` returns; sessions
+already running pick it up at their next start, since Claude Code reads
+`settings.json`'s `env` when it starts. While the pool is on, every Claude Code request
+on the machine depends on the daemon: if it isn't running, Claude Code gets "connection
+refused", and `sessionpipe pool` says so (`sessionpipe control run` in a terminal, or the
+service `pool on` installs). The daemon runs for the pool alone, with no receiver
+paired; `control off` keeps the service while the pool is on. While the daemon runs,
+every `sessionpipe pool` command goes to it over the local socket, since it holds the
+listener, the session pins and the credentials; with no daemon the command runs here and
+the daemon reads the result when it starts. From a receiver, the same actions arrive as
+a signed `pool` command; turning it on or off, removing or reordering accounts, and
+finishing a sign-in need a fresh confirm with your passkey or device key, never a day
+grant alone. `sessionpipe uninstall` runs `pool off` first.
+
 ## Updates
 
 The control daemon keeps its own copy current. About a minute after it starts, and then
@@ -153,6 +222,34 @@ sessionpipe update          # install the latest now; the daemon restarts onto i
 a launchd or systemd service doesn't inherit your shell's variables, while
 `sessionpipe update off` reaches it (it re-reads the config every ten minutes).
 
+## Session names from claude.ai
+
+A session the Claude app starts on this machine gets its name from claude.ai, a few
+seconds after its first message, and claude.ai never writes that name to the machine.
+Out of the box sessionpipe reads only local files, so such a session goes out under
+your first prompt cut to 50 characters while the Claude app shows another name.
+
+```sh
+sessionpipe titles on       # Claude Code sessions with a claude.ai link take claude.ai's name
+sessionpipe titles refresh  # ask again about the last 30 days' sessions (--days N)
+sessionpipe titles off      # local files only again (the default)
+sessionpipe titles          # which one holds
+```
+
+With it on, the worker asks claude.ai for the name of each Claude Code session that has
+a claude.ai link, a minute apart until claude.ai has named it, then every half hour. To
+ask, it reads the sign-in Claude Code keeps for that config dir (the macOS keychain item
+Claude Code writes, else `.credentials.json` in the config dir). It sends that token to
+`api.anthropic.com` alone and keeps it nowhere: not in a file, an event, a log or a
+sink. A token about to expire is skipped, never refreshed, so Claude Code's own login is
+never touched. A name you gave the session here (`/rename`) still wins, and so does a
+rename in the Claude app, which reaches the transcript without any of this.
+
+`titles on` (and `titles refresh`) also asks about every session of the last 30 days
+and sends each one a receiver already has under another name again, as
+`session.backfill` with claude.ai's name, so finished sessions are renamed too, not only
+the ones that run again. It prints how many it found named and how many it sent.
+
 ## Help and status JSON
 
 `sessionpipe <command> --help` (or `-h`) prints usage and exits successfully before

package/dist/cli.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";AAoEA,MAAM,WAAW,EAAE;IACjB,0BAA0B;IAC1B,GAAG,EAAE,CAAC,CAAC,CAAC,EAAE,MAAM,KAAK,IAAI,CAAC;IAC1B,kDAAkD;IAClD,GAAG,EAAE,CAAC,CAAC,EAAE,MAAM,KAAK,IAAI,CAAC;IACzB,IAAI,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;CAC9B;AAED,8FAA8F;AAC9F,wBAAsB,IAAI,CACxB,IAAI,EAAE,MAAM,EAAE,EACd,EAAE,GAAE,EAA2F,GAC9F,OAAO,CAAC,IAAI,CAAC,CAUf;AAED,sFAAsF;AACtF,wBAAgB,YAAY,CAAC,KAAK,EAAE,MAAM,GAAG,SAAS,EAAE,GAAG,EAAE,MAAM,GAAG,OAAO,CAM5E"}
+{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";AAwEA,MAAM,WAAW,EAAE;IACjB,0BAA0B;IAC1B,GAAG,EAAE,CAAC,CAAC,CAAC,EAAE,MAAM,KAAK,IAAI,CAAC;IAC1B,kDAAkD;IAClD,GAAG,EAAE,CAAC,CAAC,EAAE,MAAM,KAAK,IAAI,CAAC;IACzB,IAAI,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;CAC9B;AAED,8FAA8F;AAC9F,wBAAsB,IAAI,CACxB,IAAI,EAAE,MAAM,EAAE,EACd,EAAE,GAAE,EAA2F,GAC9F,OAAO,CAAC,IAAI,CAAC,CAUf;AAED,sFAAsF;AACtF,wBAAgB,YAAY,CAAC,KAAK,EAAE,MAAM,GAAG,SAAS,EAAE,GAAG,EAAE,MAAM,GAAG,OAAO,CAM5E"}