Files
tty7/.github/workflows
l0ng-ai 53f661e1a1 feat(remote): let a remote workspace target a Windows host over SSH (#1041)
A remote workspace refused any machine that was not Linux or macOS. This
teaches the installer and the link to reach a Windows OpenSSH host:

- Detection: `uname -sm` is still asked first, unchanged. When it fails
  (cmd.exe / PowerShell) or answers from Git for Windows, MSYS2 or Cygwin,
  a PowerShell probe reads PROCESSOR_ARCHITECTURE. The detected platform
  must match the SFTP home's shape, so a WSL DefaultShell over Windows
  SFTP is refused instead of installing a Linux server at /C:/...
- Assets: tty7-server-windows-{x86_64,aarch64}.exe, verified against
  checksums.txt like every other server; built by new server-windows
  jobs in release.yml and nightly.yml (ARM64 leg non-blocking), and the
  CI vcruntime guard now covers tty7-server.exe.
- Install: %USERPROFILE%\AppData\Local\tty7\bin\tty7-server-cXpY.exe via
  SFTP (/C:/... spelling). No mode bits are required or set. A running
  image is renamed aside to free its name and swept on the next install.
- Commands: every Windows command is a PowerShell script sent as
  -EncodedCommand, which survives cmd.exe, PowerShell and bash as the
  DefaultShell. The daemon is launched through Win32_Process.Create so
  it outlives the SSH session's job object, with this session's
  environment handed over; restarts use a new `tty7-server --stop`.
- Link: a Windows server is always reached by session exec with a plain
  `"C:\...\tty7-server-cXpY.exe" --stdio` (no env probe, no
  stream-local forward).
- Server: `--stdio` (control and --pane) now bridges on Windows to the
  daemon's loopback TCP endpoints instead of refusing.

Tested against a fake Windows host in install/windows_tests.rs; not yet
run against a real Windows machine.
2026-09-30 16:36:04 +08:00
..