claudemesh-cli 1.23.0 → 1.25.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.
- package/dist/entrypoints/cli.js +875 -893
- package/dist/entrypoints/cli.js.map +17 -19
- package/dist/entrypoints/mcp.js +424 -1919
- package/dist/entrypoints/mcp.js.map +6 -33
- package/package.json +1 -1
- package/skills/claudemesh/SKILL.md +7 -3
package/package.json
CHANGED
|
@@ -45,7 +45,7 @@ claudemesh send "<from_name>" "..." --mesh "<mesh_slug>"
|
|
|
45
45
|
|
|
46
46
|
If the parent Claude session was launched via `claudemesh launch`, an MCP push-pipe is running and holds the per-mesh WS connection. CLI invocations dial `~/.claudemesh/sockets/<mesh-slug>.sock` and reuse that warm connection (~200ms total round-trip including Node.js startup). If no push-pipe is running (cron, scripts, hooks fired outside a session), the CLI opens its own WS, which takes ~500-700ms cold. **You don't manage this** — every verb auto-detects and falls through.
|
|
47
47
|
|
|
48
|
-
### Daemon path (
|
|
48
|
+
### Daemon path (v1.24.0+, REQUIRED for in-Claude-Code use)
|
|
49
49
|
|
|
50
50
|
`claudemesh daemon up [--mesh <slug>]` starts a persistent per-user runtime that holds the broker WS, a durable SQLite outbox/inbox, and listens on `~/.claudemesh/daemon/daemon.sock` (UDS) plus an optional loopback TCP. When the daemon socket is present, every verb routes through it first (~1ms IPC) before falling back to bridge / cold paths. The send envelope carries a caller-stable `client_message_id`, so a `claudemesh send` that started before a daemon crash survives the restart via the on-disk outbox.
|
|
51
51
|
|
|
@@ -60,11 +60,15 @@ claudemesh daemon outbox requeue <id> # re-enqueue an aborted/d
|
|
|
60
60
|
claudemesh daemon down # SIGTERM + wait
|
|
61
61
|
```
|
|
62
62
|
|
|
63
|
-
`claudemesh install`
|
|
63
|
+
As of 1.24.0 `claudemesh install` registers the MCP entry **and** installs/starts the daemon service for the user's primary mesh. The MCP shim hard-requires the daemon to be running — it bails at boot with actionable instructions if the socket isn't present. There is no fallback. CLI verbs (`send`, `peer list`, `inbox`, `skill list/get`, etc.) keep working without a daemon via bridge or cold paths, but for any in-Claude-Code use the daemon must be up.
|
|
64
|
+
|
|
65
|
+
### Ambient mode (1.25.0+)
|
|
66
|
+
|
|
67
|
+
Once `claudemesh install` has run (registers MCP entry + starts daemon service), **raw `claude` Just Works** for the daemon's attached mesh. No `claudemesh launch` ceremony, no manual flags, no per-session keypair. Channel push, slash commands, and resources all flow through the daemon-backed MCP shim. Use `claudemesh launch` only when you need to override defaults (different mesh, custom display name, system-prompt injection, headless modes).
|
|
64
68
|
|
|
65
69
|
## Spawning new sessions (no wizard)
|
|
66
70
|
|
|
67
|
-
`claudemesh launch`
|
|
71
|
+
`claudemesh launch` remains useful for non-default cases: explicit mesh selection, fresh display name, headless `--quiet` runs, system-prompt injection, multi-mesh users with one daemon attached to mesh A who want to spawn into mesh B. For the common case (single joined mesh, daemon installed), prefer raw `claude`. Pass every required flag up front so no interactive prompt fires — that's what makes the verb scriptable from tmux send-keys, AppleScript/iTerm spawn helpers, hooks, cron, and the `claudemesh launch` you call from inside another session.
|
|
68
72
|
|
|
69
73
|
### Full flag surface
|
|
70
74
|
|