sessionpipe 0.10.0 → 0.12.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (45) hide show
  1. package/README.md +74 -0
  2. package/dist/cli.d.ts.map +1 -1
  3. package/dist/cli.js +5165 -2399
  4. package/dist/cli.js.map +4 -4
  5. package/dist/control/cli.d.ts +4 -0
  6. package/dist/control/cli.d.ts.map +1 -1
  7. package/dist/control/daemon.d.ts +24 -0
  8. package/dist/control/daemon.d.ts.map +1 -1
  9. package/dist/control/local.d.ts +24 -0
  10. package/dist/control/local.d.ts.map +1 -1
  11. package/dist/control/pool.d.ts +49 -0
  12. package/dist/control/pool.d.ts.map +1 -0
  13. package/dist/control/route.d.ts +1 -1
  14. package/dist/control/route.d.ts.map +1 -1
  15. package/dist/help.d.ts.map +1 -1
  16. package/dist/hook.d.ts.map +1 -1
  17. package/dist/hook.js +38 -2
  18. package/dist/hook.js.map +2 -2
  19. package/dist/index.js +1135 -880
  20. package/dist/index.js.map +4 -4
  21. package/dist/pool/cli.d.ts +39 -0
  22. package/dist/pool/cli.d.ts.map +1 -0
  23. package/dist/pool/credentials.d.ts +44 -0
  24. package/dist/pool/credentials.d.ts.map +1 -0
  25. package/dist/pool/import.d.ts +23 -0
  26. package/dist/pool/import.d.ts.map +1 -0
  27. package/dist/pool/index.d.ts +138 -0
  28. package/dist/pool/index.d.ts.map +1 -0
  29. package/dist/pool/install.d.ts +46 -0
  30. package/dist/pool/install.d.ts.map +1 -0
  31. package/dist/pool/login.d.ts +27 -0
  32. package/dist/pool/login.d.ts.map +1 -0
  33. package/dist/pool/policy.d.ts +100 -0
  34. package/dist/pool/policy.d.ts.map +1 -0
  35. package/dist/pool/server.d.ts +76 -0
  36. package/dist/pool/server.d.ts.map +1 -0
  37. package/dist/pool/store.d.ts +89 -0
  38. package/dist/pool/store.d.ts.map +1 -0
  39. package/dist/pool/types.d.ts +92 -0
  40. package/dist/pool/types.d.ts.map +1 -0
  41. package/dist/run.d.ts +14 -1
  42. package/dist/run.d.ts.map +1 -1
  43. package/dist/worker.js +1143 -888
  44. package/dist/worker.js.map +4 -4
  45. package/package.json +1 -1
package/README.md CHANGED
@@ -132,6 +132,52 @@ refusal, listed in the reply; auto mode allows. An agent that never asks (OpenCo
132
132
  its own settings) runs its tools as it would at your terminal. Signing in is yours to do
133
133
  at the terminal: an agent that wants it says so in the reply.
134
134
 
135
+ ## The pool: several Claude accounts, one session that keeps going
136
+
137
+ Claude Code can't change account mid-session, but its requests can. `sessionpipe pool`
138
+ keeps several Claude accounts behind one loopback listener the control daemon runs on
139
+ this machine; Claude Code is pointed at it through the `env` block of its
140
+ `settings.json` (`ANTHROPIC_BASE_URL`, `ANTHROPIC_AUTH_TOKEN`, and the one flag that
141
+ keeps its first-party features on). Each request goes to the first account in your order
142
+ that has room, a session stays on its account while that account has room, and when the
143
+ account's 5-hour or weekly window is used up the next request simply goes to the next
144
+ account: the session notices nothing. The numbers each account reports arrive as
145
+ `limits.observed` with `account_id`, so a receiver's usage page shows every account
146
+ ([spec](../../spec/CONTROL.md#pool), [what it reads](../../spec/ADAPTERS.md),
147
+ [privacy](../../spec/PRIVACY.md)).
148
+
149
+ ```sh
150
+ sessionpipe pool add --import # copy every Claude Code login on this machine into the pool
151
+ sessionpipe pool add --login # sign in to another account: a URL, then paste the code to --code -
152
+ sessionpipe pool on # write the env block; installs the daemon's service if it isn't there
153
+ sessionpipe pool # the accounts in order, each with its room left and reset times
154
+ sessionpipe pool order <id|email>… # the complete order; enable | disable | remove | refresh too
155
+ sessionpipe pool off # remove exactly what `on` wrote; the accounts stay
156
+ ```
157
+
158
+ Nothing here happens until you run `pool add` or `pool on` yourself: `install` and
159
+ `connect` never touch the pool. The credentials you add live in sessionpipe's own secrets
160
+ store (the keychain where there is one), are sent only to the vendor's own endpoints for
161
+ your own requests, and never appear on an event, in an ack or on the terminal. The
162
+ vendor is called (requests forwarded, idle usage read every five minutes) only while the
163
+ pool is on; `pool add --login` and `pool refresh` at the terminal are the exceptions,
164
+ because you asked. Whether pooling is allowed by each account's plan is yours to check;
165
+ sessionpipe doesn't change any limit.
166
+
167
+ New Claude Code sessions use the pool from the moment `pool on` returns; sessions
168
+ already running pick it up at their next start, since Claude Code reads
169
+ `settings.json`'s `env` when it starts. While the pool is on, every Claude Code request
170
+ on the machine depends on the daemon: if it isn't running, Claude Code gets "connection
171
+ refused", and `sessionpipe pool` says so (`sessionpipe control run` in a terminal, or the
172
+ service `pool on` installs). The daemon runs for the pool alone, with no receiver
173
+ paired; `control off` keeps the service while the pool is on. While the daemon runs,
174
+ every `sessionpipe pool` command goes to it over the local socket, since it holds the
175
+ listener, the session pins and the credentials; with no daemon the command runs here and
176
+ the daemon reads the result when it starts. From a receiver, the same actions arrive as
177
+ a signed `pool` command; turning it on or off, removing or reordering accounts, and
178
+ finishing a sign-in need a fresh confirm with your passkey or device key, never a day
179
+ grant alone. `sessionpipe uninstall` runs `pool off` first.
180
+
135
181
  ## Updates
136
182
 
137
183
  The control daemon keeps its own copy current. About a minute after it starts, and then
@@ -176,6 +222,34 @@ sessionpipe update # install the latest now; the daemon restarts onto i
176
222
  a launchd or systemd service doesn't inherit your shell's variables, while
177
223
  `sessionpipe update off` reaches it (it re-reads the config every ten minutes).
178
224
 
225
+ ## Session names from claude.ai
226
+
227
+ A session the Claude app starts on this machine gets its name from claude.ai, a few
228
+ seconds after its first message, and claude.ai never writes that name to the machine.
229
+ Out of the box sessionpipe reads only local files, so such a session goes out under
230
+ your first prompt cut to 50 characters while the Claude app shows another name.
231
+
232
+ ```sh
233
+ sessionpipe titles on # Claude Code sessions with a claude.ai link take claude.ai's name
234
+ sessionpipe titles refresh # ask again about the last 30 days' sessions (--days N)
235
+ sessionpipe titles off # local files only again (the default)
236
+ sessionpipe titles # which one holds
237
+ ```
238
+
239
+ With it on, the worker asks claude.ai for the name of each Claude Code session that has
240
+ a claude.ai link, a minute apart until claude.ai has named it, then every half hour. To
241
+ ask, it reads the sign-in Claude Code keeps for that config dir (the macOS keychain item
242
+ Claude Code writes, else `.credentials.json` in the config dir). It sends that token to
243
+ `api.anthropic.com` alone and keeps it nowhere: not in a file, an event, a log or a
244
+ sink. A token about to expire is skipped, never refreshed, so Claude Code's own login is
245
+ never touched. A name you gave the session here (`/rename`) still wins, and so does a
246
+ rename in the Claude app, which reaches the transcript without any of this.
247
+
248
+ `titles on` (and `titles refresh`) also asks about every session of the last 30 days
249
+ and sends each one a receiver already has under another name again, as
250
+ `session.backfill` with claude.ai's name, so finished sessions are renamed too, not only
251
+ the ones that run again. It prints how many it found named and how many it sent.
252
+
179
253
  ## Help and status JSON
180
254
 
181
255
  `sessionpipe <command> --help` (or `-h`) prints usage and exits successfully before
package/dist/cli.d.ts.map CHANGED
@@ -1 +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"}
1
+ {"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"}