@mmmbuto/nexuscrew 0.8.5 → 0.8.7

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/README.md CHANGED
@@ -16,7 +16,7 @@ panes, windows. tmux does the work; the browser is just a faithful client.
16
16
 
17
17
  ---
18
18
 
19
- ## What it is (v0.8.5 "Clean Fleet")
19
+ ## What it is (v0.8.7 "One-Link Pairing")
20
20
 
21
21
  - Runs a small server on the host where your tmux sessions live.
22
22
  - Each attach spawns a real PTY running `tmux attach` and bridges its bytes over a WebSocket
@@ -31,11 +31,17 @@ panes, windows. tmux does the work; the browser is just a faithful client.
31
31
  configuration you already control and see local, direct, and relayed tmux fleets in one UI.
32
32
  Route labels show where every session lives; creation, attach, files, lifecycle and Fleet
33
33
  management use the selected location through a scoped single-origin route.
34
+ - **One-link node pairing**: paste a link or scan its QR in Settings → Nodes. A complete
35
+ link tests SSH, exchanges the one-time invitation, confirms both directions and verifies
36
+ the peer automatically; failures identify the exact connection stage.
34
37
  - **Settings and wizard**: manage roles, nodes, token rotation, and service regeneration
35
- from the UI; a skippable first-run wizard guides initial setup.
38
+ from the UI; the first-run wizard uses the same pairing flow as Settings.
36
39
  - **Cell lifecycle from the UI**: the primary `+` creates a managed Fleet cell at Local or
37
- any reachable node. Cards expose direct power and settings controls; deletion lives in
38
- Settings Fleet. Unmanaged tmux sessions remain attachable and can be terminated there.
40
+ any reachable node. Power opens one shared launch sheet where engine, model, permission
41
+ policy and boot can be reviewed before every start; deletion lives in Settings → Fleet.
42
+ - **Legacy session adoption**: Settings → Fleet lists managed and unmanaged tmux sessions on
43
+ every route. A live unmanaged session can be explicitly imported as a managed cell without
44
+ inventing its engine, provider or model.
39
45
  - **Rich cards**: last activity, current command, a sanitized one-line preview per session.
40
46
  - **Fleet control**: a built-in schema-driven fleet manager handles cells, engines, model
41
47
  selection, and boot persistence; an existing external `fleet` CLI can take ownership through
@@ -56,20 +62,21 @@ panes, windows. tmux does the work; the browser is just a faithful client.
56
62
  The **Fleet Deck** desktop grid (≥1024px): drag sessions into a tiling layout — live
57
63
  terminals side by side, each a real PTY streamed to the browser.
58
64
 
59
- | Mobile home | Attached session |
60
- |:---:|:---:|
61
- | <img src="docs/img/fleet-deck.gif" width="300" alt="NexusCrew mobile home: the tmux fleet with live cards, cursor blinking"> | <img src="docs/img/session-window.png" width="300" alt="A tmux session attached in the browser over a real PTY"> |
65
+ <p align="center">
66
+ <img src="docs/img/fleet-mobile.png" width="420" alt="NexusCrew mobile Fleet overview with managed AI cells and direct power controls">
67
+ </p>
62
68
 
63
- The mobile home lists your tmux fleet with live cards; tapping a session attaches it
64
- over a real PTY. On the right, a `codex-vl` session running inside the browser client.
69
+ The mobile Fleet overview keeps managed cells, current engines, activity and direct power
70
+ controls in one place. Tapping a live session still attaches through a real PTY.
65
71
 
66
72
  ## Fleet integration
67
73
 
68
74
  A clean install includes the built-in, schema-driven fleet manager. Its safe defaults contain
69
75
  four CLI adapters — **Claude Code**, **Codex**, **Codex-VL**, and **Pi** — and no cells,
70
- prompts, API keys, or machine-specific paths. Engine, provider, credential-variable name,
71
- model and permission policy are configured only in Settings → Fleet; the power sheet only
72
- starts or stops the already configured cell and controls boot persistence.
76
+ prompts, API keys, or machine-specific paths. Provider, credential-variable name and reusable
77
+ engine definitions live in Settings → Fleet. When a cell is off, its shared launch sheet lets
78
+ you choose the engine, model, permission policy and boot state before starting it; the last
79
+ model and permission choice is remembered separately for each cell and engine.
73
80
 
74
81
  The concise provider catalog is scoped per CLI:
75
82
 
@@ -86,11 +93,13 @@ remain launch-compatible for existing fleets but are not provider choices for ne
86
93
  Model discovery is used where the CLI/provider documents it, with a manual model field as the
87
94
  portable fallback.
88
95
 
89
- Managed engines expose a permission selector. New Claude engines (native, Z.AI, Ollama, or
90
- custom) default to **Bypass permissions** and launch with
91
- `--dangerously-skip-permissions`; choose **Standard permissions** to disable it. New Codex and
92
- Codex-VL engines default to Standard and offer an explicit opt-in for
93
- `--dangerously-bypass-approvals-and-sandbox`. Pi keeps its native permission behavior.
96
+ Managed engines expose a permission selector both in their definition and in the cell launch
97
+ sheet. New Claude engines (native, Z.AI, Ollama, or custom) default to **Bypass permissions**
98
+ and launch with `--dangerously-skip-permissions`; choose **Standard permissions** to disable
99
+ it. New Codex and Codex-VL engines default to Standard and offer an explicit opt-in for
100
+ `--dangerously-bypass-approvals-and-sandbox`. Pi is always launched with its native Standard
101
+ permission behavior. Claude-compatible managed models also receive matching context and
102
+ auto-compaction window variables, including one-million-token profiles where declared.
94
103
 
95
104
  Custom argv-based engines remain supported. Their command, environment, cwd, and prompt are
96
105
  validated against a strict trust boundary and launched without a shell.
@@ -116,7 +125,11 @@ the NexusCrew power control starts or stops the cell without changing that confi
116
125
  and accepts `up <Cell> [--engine E] [--boot]`, `down <Cell> [--boot]`, `engine <Cell> <E>`,
117
126
  `boot|noboot <Cell>`. The binary is trust-checked (regular file, not a symlink, not
118
127
  world-writable) and the schema is validated strictly — anything else and the feature stays
119
- off. Set `NEXUSCREW_FLEET=0` to disable it entirely.
128
+ off. Automatic discovery checks the configured path, Termux's `$PREFIX/bin/fleet`, then
129
+ `~/.local/bin/fleet`; startup-service ownership uses the same resolver so built-in and external
130
+ boot managers cannot both take ownership. An explicitly pinned external binary fails closed
131
+ instead of silently switching to another executable. Set `NEXUSCREW_FLEET=0` to disable Fleet
132
+ entirely.
120
133
 
121
134
  ## Requirements
122
135
 
@@ -147,10 +160,26 @@ token travels in the URL **fragment** (`#token=…`), so it never reaches the se
147
160
 
148
161
  ## Federated Hydra nodes (configured from the PWA)
149
162
 
150
- Every installation is always the local node and can join other NexusCrew nodes. Open
151
- **Settings Nodes**, create a ten-minute pairing link/QR on one device, then paste or scan it
152
- on the other together with an OpenSSH Host alias. That single pairing creates a reciprocal,
153
- loopback-only link and both sides exchange a redacted topology automatically.
163
+ Every installation is always the local node and can join other NexusCrew nodes. The normal
164
+ flow stays entirely in the PWA:
165
+
166
+ 1. On the installation being shared, open **Settings → Nodes → Invite a node**. Enter the
167
+ OpenSSH target or Host alias that the *other device* uses to reach this installation, then
168
+ create the ten-minute link/QR.
169
+ 2. On the other device, open its own NexusCrew PWA (`nexuscrew show`), go to
170
+ **Settings → Nodes**, and use the first card, **Connect with one link**. Paste the complete
171
+ link in the prominent field or scan the QR. Do not navigate to the loopback address in the
172
+ link: it is only a portable container for the pairing payload.
173
+ 3. A complete v2 link connects automatically. NexusCrew starts a provisional SSH forward,
174
+ checks transport readiness, consumes the one-time invite once, negotiates the reciprocal
175
+ path, confirms it, and verifies authenticated federation health and peer identity. If a
176
+ stage fails, the PWA preserves the link and shows the exact stage, detail and safe retry
177
+ guidance. Older v1 links remain accepted and open only the missing routing fields.
178
+
179
+ The link never contains an SSH key, identity file, API key or PWA token. Its only credential is
180
+ the random, one-time pairing invite; SSH routing fields are non-secret configuration. A
181
+ successful pairing creates a reciprocal loopback-only link and both sides exchange a redacted
182
+ topology automatically.
154
183
 
155
184
  NexusCrew does not create SSH keys or edit `authorized_keys`. OpenSSH remains authoritative for
156
185
  identity files, agents, host keys, ports, ProxyJump and forwarding policy. NexusCrew uses
@@ -306,7 +335,7 @@ node bin/nexuscrew.js serve
306
335
 
307
336
  ## Status
308
337
 
309
- The current stable release is **v0.8.5**, published on npm under the **`latest`** dist-tag.
338
+ The current stable release is **v0.8.7**, published on npm under the **`latest`** dist-tag.
310
339
 
311
340
  ## License
312
341