mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 16:02:24 +00:00
l0ng-aiandl0ng-ai
6c26b35acc
* fix(control): bump the dialect to v6 so an out-of-date server says so The control dialect has been renamed, extended and cut since it was last numbered, all of it against CONTROL_VERSION 5: the machine tree replaced WorkspaceList/Get/Put/Delete with WorkspaceTree, MachineGet and the tab/pane verbs, GitStream arrived with its chunk and end events, and ReplyOk::Attached and FileMeta went away. A peer left behind by any of that still answers the hello, because the number it answers with still matches. It is also still sitting at the path the installer looks for, tty7-server-c5p5, so a client decides it already has the server it needs. Then the first call reaches a variant the peer has never heard of, the frame fails to decode, and the read loop takes the whole link down with it. What the user sees is a remote workspace that opens with no tabs and a git detail pane that never fills, with nothing anywhere saying why. Moving the number puts all three guards back: the hello is refused with the message that names the old build, the remote binary is looked for at c6p5 and installed rather than trusted, and a stale local daemon gets the restart prompt it should have been getting all along. Document the rule next to the constant while it is fresh: move it when a variant is added or removed. The feature strings only cover what a peer can safely ignore, and a request it cannot decode is not that. * feat(remote): publish a tty7-server for macOS hosts A remote workspace has been Linux-only for no reason anyone chose: the installer derives the asset name from `uname -sm`, and the only names it knew were the two musl builds. A Mac on the other end of an SSH profile got "a remote tty7 workspace needs a Linux host" and stopped there. Publish the two Apple slices alongside them and teach the installer to ask for them. `Darwin arm64` and `Darwin x86_64` now map to tty7-server-macos-aarch64 and tty7-server-macos-x86_64; everything past that point already worked, because nothing under it was ever Linux- specific — the install path is POSIX, the upload is SFTP, and the dialect probe runs the binary before trusting it. The machine names are matched per system rather than by architecture alone. Linux says aarch64 on one distribution and arm64 on the next, while a Mac only ever says arm64, so honouring Linux's spellings under Darwin would be guessing at output no Mac produces. Static linking is not the instrument on macOS — Apple ships no static libSystem — so assert-macho.sh stands in for assert-static.sh with the guarantee that actually matters: every dependency resolves under /usr/lib or /System/Library, so nothing the destination Mac lacks can be picked up from a build runner, and the binary carries the signature arm64 refuses to run without. Not signed or notarized beyond that, deliberately. The binary is never downloaded by the Mac that runs it: the client fetches it, verifies it against checksums.txt and writes it over SFTP, which sets no quarantine attribute, so Gatekeeper is not in the path. ASSET_X86_64 and ASSET_AARCH64 become ASSET_LINUX_*, which is what they always meant and could not keep meaning next to a macOS pair. * fix(ci): sign the x86_64 macOS server, and stop the guard flaking on it Two faults the first green run hid from each other. The linker ad-hoc signs the arm64 slice because Apple Silicon will not execute anything unsigned, and leaves x86_64 bare. That is fine on an Intel Mac, but the x86_64 server is also what an Apple Silicon box gets when it asks through a Rosetta shell, and handing that machine an unsigned binary is a guess about Rosetta nobody needs to make. Sign both slices ad-hoc in the workflow — no identity, no secrets, nothing to do with the notarized signing the GUI bundles get. The guard that caught it was itself unreliable: `codesign -dv | grep -q` under `pipefail` reports failure whenever grep wins the race, because -q exits on the first match and the writer takes SIGPIPE. Small output means the writer usually finishes first, which is why the arm64 job passed and x86_64 failed on the same signed-or-not question. Capture into a variable and match afterwards, the way the release workflow already does it. --------- Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
134 lines
5.4 KiB
Plaintext
134 lines
5.4 KiB
Plaintext
---
|
|
title: "Remote workspaces"
|
|
description: "Whole workspaces hosted on another machine — files, repos, panes, and git all stay over there."
|
|
---
|
|
|
|
An SSH pane runs one shell on a remote machine. A **remote workspace** goes
|
|
further: tty7 runs a server on the far machine, and the whole workbench points
|
|
at it. Tabs, splits, the file tree, the git panel, the diff overlay, the process
|
|
list — all of it is the remote machine's, rendered here.
|
|
|
|
Nothing is synced or copied. The repository stays where it is.
|
|
|
|
<Frame caption="Placeholder — screenshot: a remote workspace open, sidebar showing remote repos, with the machine name in the strip">
|
|
<img src="/images/placeholder.svg" alt="A remote workspace in tty7" />
|
|
</Frame>
|
|
|
|
## Connecting
|
|
|
|
<Steps>
|
|
<Step title="Open the switcher">
|
|
<kbd>⌘ ⇧ O</kbd>. Machines are listed alongside your local workspaces —
|
|
*This Computer* first, then every saved SSH profile and, on Windows, every
|
|
WSL distribution.
|
|
</Step>
|
|
<Step title="Pick a machine">
|
|
tty7 connects over the same SSH stack as everything else, so profiles,
|
|
keychain credentials, and jump hosts all apply.
|
|
</Step>
|
|
<Step title="Approve the server install, once">
|
|
The first connection asks:
|
|
|
|
> tty7 will write its server binary to *devbox* so this machine can host
|
|
> workspaces there. Nothing else on *devbox* is touched, and no sudo is
|
|
> used.
|
|
|
|
It shows the exact path, version, size, source, and SHA-256 before you
|
|
agree. Later upgrades on that machine install silently.
|
|
</Step>
|
|
<Step title="Open a workspace">
|
|
From then on the machine's workspaces are in the switcher, and a new one
|
|
opens like a local one.
|
|
</Step>
|
|
</Steps>
|
|
|
|
## What gets installed
|
|
|
|
| | |
|
|
|---|---|
|
|
| **What** | A single self-contained `tty7-server` binary |
|
|
| **Where** | `~/.local/share/tty7/bin/tty7-server-c<control>p<protocol>` |
|
|
| **Privileges** | None. No sudo, nothing outside your home directory |
|
|
| **Hosts** | Linux (x86-64 or aarch64) and macOS (Apple Silicon or Intel) |
|
|
|
|
The Linux binary is linked fully static against musl, so it runs on any
|
|
distribution whatever its glibc vintage. The macOS one links only the libraries
|
|
every Mac already has. Either way nothing is installed beside it.
|
|
|
|
The binary is named after the wire dialect it speaks, so a client and a server
|
|
that disagree never quietly half-work — tty7 installs the matching one instead.
|
|
|
|
On Windows, a WSL distribution is handed the Linux server the installer already
|
|
shipped, so a WSL workspace needs no network access at all.
|
|
|
|
## Reattaching
|
|
|
|
Remote workspaces are the point at which persistence pays off twice: the panes
|
|
survive on the remote machine whether or not your laptop is awake, and you can
|
|
reattach from a different client entirely.
|
|
|
|
A strip along the top of the window says what the connection is doing —
|
|
*connecting*, *reconnecting (attempt 3)*, *disconnected*, or *taken over by
|
|
someone else*. Reconnection is automatic; a workspace another client has claimed
|
|
says so by name rather than fighting over it.
|
|
|
|
## Deleting a profile
|
|
|
|
Deleting an SSH profile forgets every local workspace entry that connected
|
|
through it. The confirmation names the profile's endpoint and counts the
|
|
entries going with it, and the profile's keychain credentials go too. Only the
|
|
bookmarks on this computer are touched — the sessions on the remote machine
|
|
keep running, and connecting to that machine again under a new profile brings
|
|
its workspaces back into the switcher from the machine's own list.
|
|
|
|
An entry holding a live or in-flight connection is left alone, and parks once
|
|
the link drops: it stops reconnecting on its own, keeps the name of the route
|
|
that made it rather than falling back to an internal id, and its switcher row
|
|
offers **Remove entry**. The sessions behind it are still on the machine,
|
|
waiting for a new profile.
|
|
|
|
## Keeping the server current
|
|
|
|
Two dialogs you may meet:
|
|
|
|
<AccordionGroup>
|
|
<Accordion title="Update tty7's server on “devbox”?">
|
|
The machine is serving sessions from a build whose protocol this client
|
|
cannot speak. tty7 has already installed a matching server, but the one
|
|
already running is the one your sessions are on. **Update Server** replaces
|
|
it and **ends every session it is hosting** — including ones this window is
|
|
not showing. Cancel leaves the machine exactly as it is.
|
|
</Accordion>
|
|
<Accordion title="Restart tty7's server on “devbox”?">
|
|
Same consequence, deliberately: every shell on that machine ends. Workspaces
|
|
and layouts are kept and come back with fresh shells.
|
|
</Accordion>
|
|
</AccordionGroup>
|
|
|
|
<Warning>
|
|
Both of these end other people's work if the machine is shared. tty7 spells
|
|
out what will happen before either one runs — read it.
|
|
</Warning>
|
|
|
|
## What a remote pane cannot do
|
|
|
|
- **Fork an agent session.** The fork command would run against the *local*
|
|
agent, so tty7 does not offer it.
|
|
- **Move very large files through the Files panel.** Drag-and-drop across the
|
|
link is capped at what one control frame can carry; past that the panel tells
|
|
you to use [SFTP](/remote/sftp).
|
|
|
|
## From the CLI
|
|
|
|
```bash
|
|
tty7 machine ls # this machine plus every link the server holds
|
|
tty7 -m devbox ls # route any command to a linked machine
|
|
tty7 -m devbox run -- cargo test
|
|
```
|
|
|
|
`-m` matches the full link key (`me@devbox:22`) or just the host. It uses a link
|
|
the local server *already* holds — it will not dial a fresh connection, and it
|
|
says so rather than guessing. Connect from the switcher first.
|
|
|
|
[CLI overview →](/cli/overview)
|