Sharing a Node

Sharing a node extends your machine's command surface to somebody else's workloads. That is the sentence to weigh before granting anything: a share does not open a folder or a view, it opens launch, and what a grantee launches runs on your hardware, under the OS user your node runs as, with all the reach that implies. You, the owner, see grantees' work as a bare count (what they launch stays private to them unless they share it back), while admins resolve to edit on every subshell and the machine's own OS users see every pane. The asymmetries are exactly why the consequences deserve their own page.

The one asymmetry to know

Any node share, even view, lets the grantee launch their own subshells on your machine. There is no read-only level of node sharing. What they launch is private to them: invisible to you unless they share it back, on the separate axis of subshell sharing. Node shares and subshell shares are independent axes; sharing a node never hands out subshell tokens, and sharing a subshell never grants anything about its machine.

The two levels:

Stays yours no matter what you grant:

• Sharing itself: re-granting and revoking happens only from your node's page.
• Renaming the node.
• Deleting it, which revokes its key.
• stop and uninstall of the node: an edit grantee may interrupt a machine you were shared; making it unreachable until someone walks to it is a different act.
• Repointing it at a different control plane.
• Maintenance and the directory allowlist.

A grant that turns out to have been too wide is revoked by clearing it in the same dialog that set it, and remember that anything the grantee already launched keeps running: revoking a share does not terminate their subshells. Maintenance mode does.

Granting

From the node's page, open the sharing dialog and grant view or edit to specific users or to Everyone: every signed-in user on the instance. Both node lists are small, per-user places, so the picker names everyone.

The control-plane host's row

The control plane's own machine ("the row named Server") starts out shared to Everyone at edit, the seeded default that makes a fresh instance usable by everyone it admits. The row is visible and launchable at once by default; removing that share is how an admin narrows the plane's host to themselves, and the removal sticks: boot seeding never re-adds a row an admin deliberately removed. When it is removed it applies to admins too (the admin boost confers management, never launch), so an admin who deleted the row meets a "you may not launch on this node" refusal and remedies it with a share, from the row they can still see.

What the grantee cannot see

Two disclosures run the other way, and both are deliberate:

• A view grantee may launch here without learning anything about the machine: how it is supervised, where its files live, what it logs. That runtime detail appears only for the owner and for edit grantees.
• The machine's owner sees a count, not the work: how many subshells are running there is visible to whoever manages the node, which is how an owner learns the price of maintenance or a revocation, but a grantee's subshells stay theirs unless they share them.

And one disclosure neither of you controls: whoever owns the node's OS user at the machine (you, presumably) can read every pane launched there and the bearer token in each launch's arguments. A node share is therefore also a statement that the machine's local users are on your side.

See also

• Sharing a Subshell: the other axis: who may see and type into a pane.
• Directory Allowlist: bound what a grant can do with the machine.
• Maintenance Mode: stop everything on the machine, shares included.
• The threat model: the full accounting of what each verb requires.

Edit on GitHub