feat(canvas): add shared Codex sessions, SSH accounts, browser control, and nested groups

[proteus-dev]

Problem

Several NodeTerm surfaces assumed one Codex process, one login, one machine, and one direct app-server connection. That breaks down when Codex nodes share persistent app servers to save RAM or when sessions live on an SSH host:

• a process-global node id cannot identify parallel canvas nodes;
• resumes and account switches can lose canvas ownership, linked context, titles, or context-menu capabilities;
• one system login cannot represent multiple isolated local and remote Codex accounts or their separate usage;
• a local rollout is not automatically available to a Codex app-server on another machine;
• a browser node can be opened by an agent, but without an owner-scoped Browser Plugin bridge the agent cannot reliably inspect, scroll, click, or type in it.

The change also fills canvas UX gaps around terminal sharpness, image transfer, macOS gestures, node framing, nested groups, persistent inter-agent messaging, and recurring agent tasks.

Shared Codex identity and lifecycle

• Reuse one Codex app-server per machine and account over Unix WebSockets instead of starting one server per node.
• Carry a distinct NodeTerm node id and control endpoint through each CLI session; no process-global static node id.
• Keep tmux sessions and shared app-servers alive when Electron quits, then reconnect nodes after restart.
• Package the Codex relay as an Electron resource and deploy a bundled relay/launcher to connected SSH hosts; remote hosts need Node.js, Codex, and SSH, not a NodeTerm checkout.
• Bind fresh, resumed, and in-TUI-resumed threads to their actual canvas node.
• Resolve Codex-owned session titles and update node chrome after create/resume.
• Create direct resumes as full Codex agent nodes with restart, account, linked-context, mailbox, and canvas-control capabilities.
• Preserve legacy system-account mappings while failing closed on invalid, missing, duplicate, tampered, or cross-account ownership.
• Close upgraded WebSocket clients during shutdown so relay clients cannot strand the server.

Machine-scoped Codex accounts and SSH sessions

• Group account settings by machine: this Mac and each configured SSH host appear once, with their system and managed accounts listed below them.
• Support isolated managed Codex logins on local and SSH machines, including remote device login, retry, removal, and system-account discovery.
• Keep credentials and per-account app-servers on the machine that owns them.
• Show the same account identity and Local/SSH provenance pills in Settings, node headers, create menus, and account-switch menus.
• Let new local or remote Codex nodes select the appropriate system or managed account.
• Switch accounts on the same machine by resuming the same conversation id rather than silently forking it.
• Copy an idle local Codex conversation to a selected SSH account, preserve its conversation id, verify the remote app-server can discover it, and only then recycle that node onto the SSH host. The local rollout remains available.
• Stage cross-machine rollout copies under a private remote directory, install atomically, and never overwrite an existing remote rollout.
• Aggregate account-specific session selection and usage without mixing values between accounts; ambiguous ownership fails closed.
• Prevent an explicitly selected missing account from falling back to another login.
• Upload pasted/dropped files and screenshots to the owning SSH host before inserting their paths into remote terminals.
• Give remote Codex nodes the same restart and account context-menu surfaces as local Codex nodes, scoped to accounts on their host.

Node-authenticated thread ownership

• Give each Codex node a distinct HMAC capability instead of allowing the shared hook bearer to select an acting node from the request body.
• Validate that capability on thread start, bind, observed, authorize, expose, and catalog operations.
• Forward the node capability through the shared relay without placing the secret in relay process arguments.
• Sign persisted thread/account/node/endpoint mappings and verify the signature before Browser Control accepts ownership.
• Store the signing secret encrypted with Electron safeStorage; unavailable protected storage fails closed without a plaintext fallback.
• Reject missing, invalid, cross-node, and tampered ownership claims before they reach thread handlers.
• Allow legacy unsigned mappings to be migrated by an authenticated rebind, but never use them to authorize Browser Control.

Browser control

• Expose only Browser nodes owned by the requesting Codex node to the bundled Codex Browser Plugin.
• Bridge the official in-app-browser protocol to Electron webview guests through owner-scoped CDP sessions.
• Support inspection, focus, mouse/keyboard input, click, navigation, and real scrolling.
• Restore browser ownership after an app restart.
• Clean debugger listeners and child CDP sessions on detach/close, including already-destroyed webContents, preventing close-time crashes and stale-session reuse.

Inter-agent mailbox and Loop automation

• Add persistent send, reply, and status commands for existing NodeTerm agent nodes.
• Generate timestamp, human-readable node title, stable project/node address, sender, recipient, message id, and reply instructions for every delivery.
• Distinguish durable queued acceptance from delivery into an agent turn.
• Deliver through the agent mailbox without creating replacement sessions or typing into terminal input.
• Add visible, persisted Loop nodes that deliver a task to one or more agent nodes on a configured cadence.
• Let users and agents create, update, start, pause, run immediately, inspect, and delete Loops through canvas control; deletion remains confirmation-gated.

Canvas, terminal, and file UX

• Paste screenshots/images onto the canvas and drag image files from Finder through the existing Open File path.
• Keep paste/drop disarmed over terminals, dialogs, settings, usage UI, editors, and other keyboard/input surfaces.
• Copy selected local file-backed nodes to the macOS clipboard as Finder-compatible file references.
• Route macOS two-finger trackpad gestures to canvas panning while preserving native two-finger scrolling inside terminal/native-scroll surfaces.
• Keep an active trackpad sequence on the pan path even when Chromium emits a quantized wheel packet; ordinary mouse-wheel zoom and Cmd/Ctrl-wheel or pinch zoom remain available.
• Reuse the Sessions-sidebar framing rules when double-clicking a node, so navigation has one padding and zoom contract.
• Use xterm's DOM renderer for the macOS auto default to keep terminal text sharp after drag operations; explicit renderer settings remain available and Linux/Windows defaults are unchanged.

Nested groups and Sessions sidebar

• Allow groups inside groups instead of enforcing a one-level model.
• Make group bodies click-through for normal canvas panning; movement remains on the group header.
• Support Shift-click additive selection and context-menu moves into an existing selected group.
• Keep worktree/cwd inheritance correct through ancestor groups.
• Render groups recursively in the Sessions sidebar as a tree with persisted disclosure state.
• Keep row clicks for navigation while the disclosure chevron alone expands/collapses a group.
• Drag sibling groups to reorder them inside their current parent while retaining session drag-to-group behavior.
• Keep nested group order and parentage stable across workspace persistence.

Safety properties

• no process-global NodeTerm node identity;
• no app-server per node;
• no hard-coded SSH host or Ubuntu-specific product path;
• shared hook authentication cannot assign a Codex thread to an arbitrary sibling node;
• signed ownership mappings are required before Browser Control resolves a thread to a node;
• same-machine account switching and cross-machine copying preserve the requested conversation id;
• explicit known-session resume cannot silently create a replacement conversation;
• cross-machine copy retains the source and never overwrites an existing target rollout;
• ambiguous account ownership fails closed;
• browser routing compares authenticated thread ownership with browser ownership;
• browser teardown never calls debugger APIs on destroyed contents;
• managed-account storage failures cannot fall back to another login;
• canvas paste never steals text intended for a terminal or editor.

Verification

• npm run typecheck: passed after rebasing onto current main.
• npm run build: passed after rebasing onto current main.
• Current account/SSH/gesture/navigation changed-scope run: 12 files, 194 tests passed.
• Expanded ownership/security regression run: 14 files, 177 tests passed.
• Focused ownership/relay regression run: 6 files, 69 tests passed.
• git diff --check: passed.
• Local macOS ARM64 bundle built and exercised in the packaged app.

No release publishing, production deployment, Developer ID signing, notarization, or release-pipeline dispatch is part of this PR.

[eneskirca]

The hook token authenticates a session, not which node — and three open PRs now rest on it

Cross-cutting review note, posted on both #112 and #113 because neither can fix this alone and the fix is the same in both. #98 sits on the same ground.

The mechanism

hookServer mints one randomUUID() for its whole lifetime (src/core/agents/hook-server.ts:171) and buildPtyEnv injects that same value into every session it spawns (:453). Request handling checks only that token (:180), then reads the acting node straight out of the request body — parseControlBody's form.nodeId for /control/*, and form.nodeId again on the /codex-thread/* routes (:189, :220, :246).

So the token proves "some session nodeterm spawned is calling". It proves nothing about which node is calling. Any control-capable agent can put a different node's id in the body and the server has no way to tell.

That was tolerable while a forged nodeId only mis-attributed an edge or a cwd. These PRs change what it buys.

What it buys in each PR

#113 — per-pair trust. pairKey = [sourceNodeId, args.node].sort().join('|') makes the asserted source id one half of the grant key. Agent C, holding the same env token, can send nodeId=A and deliver into B under the A↔B grant it was never given. The dialog the grant is meant to replace never appears — that is the grant's whole purpose, so there is no second gate behind it. The global toggle is honest about being blunt ("Any control-capable agent can then type into any node's terminal unseen"); the per-pair mode reads as the precise alternative, and precision is exactly what the asserted id cannot deliver.

#112 — thread ownership, and through it, browser control. The browser router does the right thing: it demands guest.ownerNodeId === nodeIdForSession(session_id) (browser-use-backend-core.ts:281). But that mapping is writable over /codex-thread/bind, whose nodeId comes from the body. bindCodexThreadIdentity refuses only when the thread is already bound to another live node (codex-identity-proxy.ts:165-167); an unowned or dead-owner thread binds freely to whatever node id the caller names (:175). Chain: find a real unowned thread id → bind it to victim node B → connect to the browser socket claiming that session → requireTab now resolves to B, and you can inspect, click, type and navigate B's browser node, including whatever authenticated session B has open. The ownership check is sound; the thing it checks against is attacker-writable.

#98 — same ground, smaller blast radius. notify verifies the source is context-linked to the target, but the source is the asserted id. With list returning every node id on the project, an unlinked agent can iterate ids as claimed sources until one satisfies the link check. The payload is a fixed string, so this is noise-injection rather than takeover — but it is the same gate resting on the same assertion.

Scope, stated plainly

All of this lives inside one OS user. Nothing crosses the user boundary: the hook server is loopback, the browser socket is 0600 in a 0700 dir, and an attacker who already has that uid can read the files directly. The realistic threat is a prompt-injected or misbehaving agent moving laterally to a sibling node — which is precisely the boundary #112's browser scoping and #113's per-pair grants are advertised to enforce.

The fix

Bind the token to the node, and stop reading identity from the body:

1. buildPtyEnv mints a per-node token instead of handing out the server-wide one, and registers token → nodeId in a map alongside the existing session bookkeeping.
2. Request handling resolves the acting node from the token (tokenMatches becomes nodeForToken), and nodeId in the body is either dropped or required to equal the resolved node.
3. Sessions outlive the app, so the map must survive a relaunch — the endpoint file (hook-server.ts:435) already carries the restart handoff and is the natural place for the per-node entries. Unknown token ⇒ 403, which is the safe degrade.

That is one change in src/core/agents/hook-server.ts plus its buildPtyEnv callers. It closes #113's grant spoof and #112's bind spoof at once, and turns #98's link check into something that means what it says. Doing it per-PR instead would mean three partial defenses over the same hole.

Two smaller things worth folding in while that seam is open, both from #112: /codex-thread/observed lets a caller set another node's title (index.ts:1003), and the CDP passthrough in browser-use-backend-core.ts:366 forwards any method with no allowlist — so a controlling agent can Page.navigate to file:///… then Runtime.evaluate. Harmless against your own node; a file-read primitive against a victim's once the ownership above is forgeable.

What I verified, and what I did not

Read and confirmed in the code: the single token and its identical injection (:171, :453), the body-sourced nodeId on /control/* and /codex-thread/bind (:189, :220), bindCodexThreadIdentity's live-only refusal (:165-175), the browser router's ownership check (:281), and #113's pairKey construction.

Not verified by running: no crafted POST was actually sent, and neither the bind→browser chain nor the grant spoof was reproduced end to end. Both are read off the code, and a multi-account setup with a live browser node is what would settle them. If either of you sees a check I have missed on the path from a forged body to the acting node, I would rather be wrong about this.

Credit where due: #112's cross-account resolution genuinely fails closed (duplicate thread ids resolve ambiguous unless one inode proves otherwise), its rollout hardlinking is carefully defended, and #113 fixes a real bug — the 2 s slowloris guard was killing confirmation-gated /control/write and /control/close outright, so agent messaging only worked if the user clicked within two seconds. Neither PR created this weakness; they inherited it and lean on it harder than anything before them.

[proteus-dev]

Addressed the #112 thread-ownership/browser-control path in 1a73cfc.

The shared hook bearer can no longer choose the acting Codex node through a request body:

• each Codex node receives a node-bound HMAC capability;
• thread start, bind, observed, authorize, expose, and catalog validate that capability before invoking their handlers;
• the shared relay forwards the capability while keeping it out of process arguments;
• persisted thread/account/node/endpoint mappings are signed, and Browser Control resolves ownership only from a valid signature;
• the signing secret is encrypted with Electron safeStorage and the feature fails closed if protected storage is unavailable;
• unsigned legacy mappings can be migrated by an authenticated rebind, but cannot authorize Browser Control.

This uses a keychain-protected root secret plus deterministic per-node capabilities rather than persisting a token map in the endpoint file. That preserves node identity across an Electron relaunch without putting node capabilities in the shared endpoint handoff.

The focused negative coverage includes missing/wrong node capabilities, mismatched body node ids, tampered persisted ownership, relay forwarding, and protected-secret failure. Typecheck, build, 177-test expanded regression coverage, a final 69-test ownership/relay run, and diff-check pass.

This closes the #112 bind-to-victim chain and the related observed-title spoof. It does not claim to change the separate generic /control/* identity seam discussed for #113.

[proteus-dev]

Updated after rebasing onto current main and resolving the terminal-renderer overlap with the upstream offscreen-disposal work.

New in the PR head:

• machine-scoped local and SSH Codex accounts with one shared app-server per machine/account;
• remote system-account discovery and managed device-login setup;
• consistent account/provenance presentation across Settings, node headers, and menus;
• atomic local-to-SSH conversation transfer that preserves the thread id and retains the local rollout;
• remote screenshot/file upload into SSH terminals;
• native two-finger terminal scrolling plus stable canvas panning without intermittent wheel zoom.

Post-rebase verification: typecheck passed, build passed, 12 changed-scope test files / 194 tests passed, and git diff --check passed.

[eneskirca]

Status update, so this isn't sitting here unexplained.

Not merging this as a unit — 18,671 lines across 115 files spanning four unrelated features is not reviewable as one change, and it has been landing in slices instead. Where each slice stands:

Already on main (extracted and merged): the canvas utilities are all in — src/main/clipboard-files.ts, src/renderer/canvas/canvas-file-copy.ts, src/renderer/canvas/canvas-image-import.ts, and src/renderer/canvas/wheel-gesture.ts all exist on main today. Thank you for those; they were the cleanest part of the PR and they went in close to as written.

Measured and dropped: the shared-Codex-identity work (codex-accounts-core.ts, codex-identity-proxy.ts, codex-relay-daemon.ts, AccountIdentityPills.tsx). The RAM saving that motivated it was measured and does not hold — it is a net loss below roughly eight nodes, which undercuts the Eco work. Not a code-quality judgement; the premise just didn't survive measurement.

Blocked on decisions I owe you, not on the code: browser-use-backend (browser control) and the nested-groups work. Both are product-shaped questions about surface area rather than review comments I can write.

Superseded: src/renderer/state/agentMailbox.ts. Agent messaging is being redesigned right now and I do not want you rebasing onto something that is about to move.

The one piece nobody has triaged

src/renderer/lib/nativeLoop.ts + src/renderer/nodes/NativeLoopNode.tsx + workspace.native-loop.test.ts is the only slice that has neither landed nor been ruled out, and it deserves better than being buried here. The core module is ~40 lines, pure, and genuinely well thought through:

• nextLoopRun explicitly refuses to create a catch-up burst after the machine wakes from sleep, which is the bug most schedulers ship with
• parseLoopInterval has a tight ^([1-9][0-9]*)(m|h|d)$ grammar with Number.isSafeInteger plus range clamping, so the canvas-control cadence string cannot produce a nonsense timer
• loopMessageId is deterministic, which is what makes at-most-once delivery possible

The catch is that its whole reason to exist is delivering a message on a schedule, so it sits directly on top of agentMailbox — the superseded piece. It should be sequenced after the messaging redesign, not before, and at that point it is a small, self-contained PR I would like to see on its own.

If you would rather not carry this branch while that happens, closing it is reasonable — the extracted slices are already on main with your authorship, and NativeLoop is small enough to re-cut fresh against the new messaging shape. Your call, and either way I owe you the browser-control and nested-groups decisions.