mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 08:02:24 +00:00
perf/diff-overlay-virtual-rows
15
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  
|
b2d73ec68b |
feat(update): update an all-users Windows install through one UAC prompt (#562)
* fix(update): surface a failed install instead of silently re-prompting (#540) The GUI quits as soon as tty7-updater is spawned, so an install that failed inside the helper left a trace only in update.log — and because launching the helper had already cleared the prompt state, the next check offered the same version again, and again. The failure mode the user saw was an app that nagged about an update it could not install. The helper now writes update-outcome.json beside update.json on every terminal path it can still reach, and the next GUI launch folds it into the update state: a failure shows in Settings with the installer's own reason until dismissed and stops the version from re-prompting on its own; a success at the running version retires a failure an earlier attempt recorded. A leftover result that exists but cannot be parsed is reported rather than dropped — something ran, and "unreadable" is a result too. The same change moves the config directory off the environment and onto the command line (--config-dir). An elevated child process does not inherit the spawner's environment, so TTY7_CONFIG_DIR would have fallen back to the administrator's config directory exactly in the over-the-shoulder case — the groundwork this lays for #504. The updater re-exports the variable for the helper children it spawns itself, so the relaunched app keeps answering for the same config directory. * feat(update): update an all-users Windows install through one UAC prompt (#504) An Inno install under C:\Program Files could not be replaced in place: the updater ran the release Setup as the signed-in user, which either installed a second, per-user copy beside the real one or let Inno re-launch itself elevated — a bare UAC prompt for an unsigned executable in %TEMP%, seconds after the GUI had vanished. So the layout was refused outright and told to download by hand. It now updates itself, with the split the design in #504 settled on: one UAC prompt covering two privileged stages, and one watcher that is never elevated at all. - The GUI probes the *installed* updater for the new verbs by running it ("capabilities"), so a side-loaded or downgraded binary answers for itself instead of being trusted by version number. An updater that predates the verbs exits with a usage error, and the install falls back to pointing at the release page exactly as before — the first release carrying this still updates the old way, and the one after it updates itself. - The prompt dialog says the UAC prompt is coming before the app quits, and stops offering "Install on Next Launch": nobody is there to answer a prompt before the first window exists. The same guard keeps a staged plan from being armed for the next launch, and apply_pending_at_launch leaves an elevation-needing plan staged rather than raising a windowless prompt at boot. - "Install now" spawns the watcher first (medium integrity, the signed-in user's token, so the relaunched app is never elevated), then ShellExecuteEx "runas" on the installed updater — the trust root a medium-integrity process cannot rewrite. Everything the elevated half needs crosses as command-line arguments, because an over-the-shoulder child inherits neither the environment nor the user's profile. The package's expected SHA-256 crosses the same way, from the checksums the GUI already holds in memory, so a payload and its checksums file cannot be rewritten together behind the IL boundary. - The privileged first stage re-verifies the payload against that digest, pins its helper byte-for-byte to the installed updater, stages both in a fresh administrator-only %ProgramData% directory (an explicit SDDL DACL, swept of stale directories first), and only then runs the install stage — which runs Setup silently, writes the outcome file, and never touches the app binary itself. The watcher follows the chain through the status file and pid liveness (ERROR_ACCESS_DENIED from OpenProcess still means "alive" across accounts), then relaunches the app de-elevated and probes that it actually came up. - Declining the UAC prompt is not an error: the watcher is reaped, nothing ran elevated, and the staged package simply waits in Settings. Persisted plans from before this protocol serde-default a plan version that is_usable rejects, so a stale plan is discarded instead of failing against a helper that would not understand its arguments. The installer script's explorer-menu registration gains skipifsilent: a silent run *is* this update path, and launching the app there would write the menu into the administrator's hive under over-the-shoulder elevation. One note on the test suite: ui::remote_connect's a_routed_auth_prompt_carries_the_machine_that_raised_it fails under parallel test execution on this machine both with and without this change — a pre-existing flake, unrelated. * fix(update): run the UAC request off the UI thread Real-machine verification of the elevated chain caught this on the first click: ShellExecuteExW pumps the calling thread's message loop while the shell raises the consent prompt (its change notifications re-enter the window), and from the UI thread that re-enters gpui with its App already borrowed — the process aborts on a RefCell double-borrow before anything ever elevates. The launch — watcher spawn included, so the pairing stays atomic — now runs on the background executor, and only the bookkeeping (quit / decline / failure) comes back to the UI thread. * fix(update): throttle a failed version instead of retiring it (#540) Per the review on #540: a failed install must not keep the version retired via last_prompted — record last_prompted plus a fresh remind_after deadline (the same three days "Later" uses), so the version asks again once the reminder expires. should_prompt already treats "last_prompted matches, reminder expired" as prompt-again, so no logic change is needed there, and the pinned a_failure_lets_the_version_prompt_again test still holds. Also write update-outcome.json *before* relaunching the previous app on the macOS/Windows/portable non-elevated paths: the GUI that comes up next is exactly the process that absorbs the outcome, and it used to be relaunched before the failure existed on disk. The elevated chain is unchanged — its watcher already waited for the file. * fix(update): let only the elevated updater's own image name the trust root Three holes on the privileged side of the #504 chain, all of the same shape: a value that decides what runs elevated was taken from the medium-integrity caller. - `elevated-stage` pinned the staged helper against `<install-dir>\tty7-updater.exe`, where `<install-dir>` is a command-line argument. Both halves of that comparison were the caller's to choose: name a directory holding two copies of any binary and the pin passes, then stage 2 runs it elevated. The stage now derives the installation from its own image — UAC pointed the prompt at `{app}\tty7-updater.exe`, so `current_exe` is the one path nothing below the boundary could have written — and passes that on to stage 2. A caller that named a different directory only gets a line in the log. - The staging directory's DACL let no standard user in, but its parent did: `%ProgramData%` grants Users the right to create directories, and the creator owns what it creates. A pre-created `%ProgramData%\tty7` gave its owner delete-child over the administrator-only staging inside it — enough to rename the verified staging aside and drop an identical name of their own into the gap between the digest check and the execute. The root is now created with the same protected descriptor, taking down whatever holds the name first; `CreateDirectoryW` applies a descriptor only when it is the one creating the directory, so succeeding is the proof. The per-run sweep goes with it — the root's removal takes the leftovers. - The GUI aimed the prompt at the updater the *plan* named, and `update.json` sits in the user's config directory. It now aims at the installation this process runs from, so the binary the prompt names is the binary that starts. Also quote the elevated command line the way `CommandLineToArgvW` reads it back: a backslash escapes only in front of a quote, so a config directory ending in one used to escape its own closing quote and swallow every argument after it, `--result-file` — the file the watcher waits on — included. * test(update): pin the elevated stage's trust root to its own image A regression test for the shape of the hole rather than the hole: if `installed_root` ever goes back to reading an argument, the pin the elevated stage runs before executing the staged helper stops meaning anything, and nothing else in the suite would notice. * fix(update): bring tty7 back when the elevated chain never reports The watcher's two timeouts returned without relaunching. Every other way out of the chain ends with the app back on screen, but a stage 1 that died before writing its status or its outcome — killed, crashed, an AppInfo service that never delivered it — left the user with the GUI already quit, nothing to replace it, and nothing said. Same for an install still running an hour later. Both paths now end the way the others do: an outcome the watcher wrote itself, then the relaunch. The synthesized outcome is written whether or not the relaunch succeeds, which also closes the same gap on the pre-existing "the elevated updater exited without recording a result" path — the next launch can name what happened instead of silently offering the version again. What kept those paths from relaunching was the risk of a second window beside a GUI that is still up: a declined prompt leaves this process running, and the kill that reaps its watcher can lose. The watcher now takes the GUI's pid and opens a handle to it at startup — while the GUI is provably alive, since it is sitting in ShellExecuteExW waiting on the prompt — so the number cannot be recycled out from under it. Before relaunching, a GUI that is still alive is waited out for 30 seconds: one that is quitting (a chain that failed fast can beat it out the door) is gone well inside that and gets its relaunch, one that is staying is recognized as staying and gets neither a relaunch nor a failure record it did not earn. A live process always answers to its own pid, so the check cannot be wrong in the direction that double-launches. Also give the Japanese elevation notice its closing 。 * fix(update): poll the parent out across the elevation account boundary Under an over-the-shoulder elevation the install stage runs as the administrator, and OpenProcess on the signed-in user's GUI answers ERROR_ACCESS_DENIED - the same boundary pid_alive already documents from the watcher's side. wait_for_exit treated that as a fatal error, so the chain recovered and reported a failure before Setup ever ran. The wait now degrades to polling the pid until it stops answering, bounded so a recycled pid cannot hold the install hostage forever. --------- Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com> Co-authored-by: l0ng-ai <l0ng-ai@users.noreply.github.com> |
||
 l0ng-aiandl0ng-ai
|
741c863c2c |
fix(windows): make the install directory actually replaceable before updating (#403)
* fix(windows): make the install directory actually replaceable before updating
The updater stopped the daemon and started the Inno installer the moment
the daemon's endpoint disappeared — but the endpoint going away is not
the same event as the images being released. The ConPTY hosts
(OpenConsole.exe) are the daemon's children, not the shells', so the
per-pane kill never reached them, and the daemon's exit(0) skipped every
destructor that would have closed them; they kept the installed
OpenConsole.exe open for seconds after --stop-daemon returned. Silent
Setup then hit the lock, took the suppressed dialog's default (Abort),
and the updater's recovery relaunched the old build — "updated,
restarted, still the old version". A daemon that died without cleaning
up made it permanent: its orphaned hosts survive indefinitely, which is
the DeleteFile-code-5 users hit even after "closing everything".
Reproduced both shapes in isolation before fixing: with a pane open,
--stop-daemon returned ~1s in while OpenConsole.exe stayed locked for
another ~1.4s; after taskkill on the daemon, the orphaned host held the
lock forever.
The shutdown now finishes what it starts, at every layer that can be
the last one standing:
* The daemon reaps its remaining descendants and waits for them
before exiting, while the endpoint — the signal stop() watches —
is still up.
* stop() reads the pidfile before asking, and waits for that process
to actually exit after the endpoint goes, not just stop listening.
* The recorded-daemon reap waits for the images to be released
instead of returning on the async TerminateProcess.
* stop_for_update(dir) — reached via --stop-daemon
--update-install-dir, which PrepareToInstall and the portable
updater now pass — also terminates anything still running from the
installation directory (the orphan case no pidfile can name) and
only returns once the .exe/.dll images there open for writing,
naming the holdouts in the error if they never do.
* The updater runs that clearing itself before invoking Setup, so a
directory that cannot be cleared fails with a cause in update.log
and relaunches the previous build, instead of Inno's bare
"DeleteFile failed; code 5".
The update dialog on Windows also told a macOS truth — "the background
service keeps running, so whatever is open in your panes survives".
Windows cannot replace a running daemon's image, so its install path
stops the service; the dialog now says so.
* fix(windows): tighten the install-dir clearing per review
- An image that fails to canonicalize stays in the lock check instead of
being silently skipped; only a positive match against the caller's own
running image is excluded.
- reap_recorded_daemon shares one deadline across the whole tree via a
new winproc::terminate_and_wait_all, which stop_for_update and
reap_descendants_of now use too — one implementation of "terminate,
then wait, bounded overall" instead of three.
- [UninstallRun] passes --update-install-dir "{app}" like
PrepareToInstall, so uninstalling after a daemon crash gets the same
orphaned-ConPTY-host cleanup as upgrading.
* fix(update): close three gaps the update audit found
- macOS updater: wait for the parent by watching getppid() reparent to
launchd instead of polling kill(pid, 0), which a recycled pid could
satisfy forever. The kill loop remains only for a hand-run updater.
- Windows: a new update guard (config-dir update.lock, held by the
updater from daemon stop to relaunch) makes ensure_running refuse to
spawn a daemon mid-install, so a tty7 CLI call or manual launch can no
longer relock the images the installer is replacing. Stale guards —
dead writer or past the TTL — are shed on sight.
- Windows portable: the update backup now carries an incomplete marker
from before the first file moves until the replacement lands. At
launch the app reports a backup still carrying it as an interrupted
update (the installation may mix two versions; the old files are
preserved), and silently removes marker-less backups a finished
update failed to delete past an antivirus hold.
* fix(update): verify the guard's writer by start time, and guard manual Setup runs
Review round three, both findings and all three minors:
- The guard no longer expires a live, verified holder: a pid is believed
to be the writer only if the process behind it started before the
guard was written (winproc::creation_time via GetProcessTimes), which
is what tells a genuine holder from a recycled pid. The TTL now bounds
only the unverifiable case, so an install slowed past ten minutes by
an antivirus sweep keeps its protection.
- Manual Setup runs get the guard too: the --stop-daemon
--update-install-dir helper holds it in its parent's name — the Setup
or uninstaller that keeps replacing files after the helper returns —
and it goes stale when that parent exits. ensure_running gained five
seconds of patience so the post-install "Launch tty7" click, racing
Setup's own exit, gets its daemon instead of an error.
- processes_running_from also matches images against the canonicalized
install-dir spelling (junction, subst, 8.3 given form).
- reconcile_portable_backups reports every interrupted backup, not the
first.
- The unix signal-and-wait loop now reuses wait_for_recorded_exit.
* style: rustfmt
---------
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
|
||
|
l0ng-aiandl0ng-ai
|
3ae340408b |
fix(windows): bundle Microsoft's ConPTY so panes can answer color queries (#360)
* fix(windows): bundle Microsoft's ConPTY so panes can answer color queries
The in-box conhost swallows a pane process's OSC 11 background query: it
never reaches tty7's emulator and no reply is ever written back, so
applications that choose a light or dark UI from the terminal background
render a dark UI under a light theme.
tty7 already answers OSC 10/11/12 from the live theme, so nothing was
missing but a pseudoconsole that forwards the question. Microsoft ships one
as a redistributable, and portable-pty already prefers a sideloaded
conpty.dll over kernel32's, so this is packaging rather than code: the pair
goes beside tty7-app.exe, where the DLL search path finds it.
Measured on Windows 11 26200, same binary, only the pair added beside it:
in-box conhost: the terminal side never sees the query; the client times
out with no reply
bundled ConPTY: the terminal side sees ESC]11;?BEL and a real pane reads
back rgb:efef/f1f1/f5f5 under catppuccin_latte, which is
the preset's exact background
The two files are one supported unit, so the release verifier fails a
package that carries only one, a mismatched pair, or the MIT notice-less
DLL. They also join PORTABLE_MANAGED_ROOTS, without which the updater would
reject every portable archive that contains them; they are deliberately not
required by verify_portable_payload, since tty7 runs without them and a
packaging slip should fail the release rather than a user's update.
build.rs stages the pair beside cargo's output so a development build does
not quietly run on the in-box host, and the daemon logs which pseudoconsole
it got.
Closes #345
* fix(windows): restage the bundled ConPTY when it goes missing
Watching only the vendored sources meant a staged copy that left the target
directory stayed gone: the build script was cached, so it never ran again to
put it back, and the build silently fell back to the in-box conhost. Cargo
treats a rerun-if-changed path that does not exist as changed, so naming the
destinations makes the staging self-healing.
Found by deleting target/debug/conpty.dll and watching the next build not
bring it back.
---------
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
|
||
|
l0ng-aiandl0ng-ai
|
2fa518a767 |
refactor(settings): rescope the About page (#350)
About had grown three sections that change system state and that nobody looks for under "About": a PATH install, a registry write, and a daemon restart. Two of them move out. The `tty7` CLI goes to Agents. That page already describes tty7 <-> agent integration in one direction (hooks reporting session status); the CLI is the other direction, and its own description leads with "so scripts and coding agents can drive tty7". The Loading and Unavailable arms there no longer return early, since the CLI toggle is about this GUI's own host rather than whichever machine the hook rows describe. The Windows Explorer context menu goes to the installer, which is where VS Code and Git for Windows put theirs: writing shell verbs is an install-time decision, not a runtime preference. A task checkbox drives new `--register-explorer-menu` / `--unregister-explorer-menu` flags, so the key layout stays in core::explorer_context_menu instead of being copied into the .iss. `status()` existed only to paint the settings UI and goes with it. The uninstaller unregisters unconditionally: an install that registered once and was later upgraded without the box ticked still holds keys that would otherwise point at a deleted exe. Server restart stays — it is about the app itself. Also fixes localization the About section had skipped: eight hardcoded English strings in the update block now have keys, and the orphaned SettingsCheckUpdatesDesc key (which still claimed "tty7 never updates itself", contradicted by the macOS in-app updater) is reused for a one-line description in place of a 60-word account of the updater's internals. Finally, terminology in the Chinese UI. hook, agent, worktree, diff and fork are read and spoken in English by Chinese developers, so translating them lost more than it gained. Scrollback was worse than a style question: 回滚 means rollback, the opposite direction. 窗格 for pane is kept — that one is standard. Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com> |
||
 
|
603bca171e |
feat(updater): add windows updates and cross-platform nightly support (#330)
* feat(updater): add windows online updates
* feat(updater): support online updates for windows portable zip builds
f
* feat(updater): support online updates for nightly build
* fix(updater): strengthen post-download update verification
* feat(updater): support explicit stable and nightly channel switching
* fix(i18n): localize update settings ui
* fix(settings): prevent slider value labels from wrapping
* feat(updater): drop the nightly channel, refuse all-users Windows installs
Follow-up to the Windows updater work on this branch, applying maintainer
review.
Nightly is a build channel, not an update channel. The updater consults
`/releases/latest` again and nothing else, so it behaves on Windows exactly
as it already does on macOS: a Nightly build is offered the stable release
that supersedes it and graduates out of the prerelease, and no rolling
prerelease can become a source of code that gets executed on a user's
machine. Removed with it: the `UpdateChannel` enum and its version-string
inference, the `tags/nightly` query, the cross-channel version-ordering
bypass, the Settings → About channel row, the rolling-tag
`update-manifest.json` and the i18n keys that only served them.
`parse_version` and `is_update_available` are byte-identical to main again.
Nightly builds are untouched, and still carry tty7-updater plus the macOS
update archive — a Nightly user needs a working helper to reach the stable
release that replaces their build.
An all-users Windows installation is no longer updated in place. Running the
release Setup silently as the signed-in user cannot replace
`C:\Program Files\tty7`: Inno resolves `{autopf}` to `%LocalAppData%\Programs`
and installs a second copy beside the real one, or re-launches itself
elevated and puts a bare UAC prompt for an unsigned executable in `%TEMP%` in
front of a user whose GUI just vanished. tty7 declines both and points at the
release page. Detection reads Inno's own `HKLM` state for the frozen AppId and
independently probes whether the directory accepts writes, so a relocated or
pruned installation is caught too; the decision is a pure function with unit
tests, and it is re-checked before the download as well as during it.
Release and Nightly now verify the Windows packages they just built, mirroring
the macOS update-archive step: the install marker, tty7-updater.exe, the ZIP
layout the updater will accept and the PE versions it will demand. Every fact
the updater checks on the user's machine after downloading is checked here
instead, so a packaging mistake fails the build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
|
618855cf4a |
fix(windows): brand toast notifications with a tty7 AUMID (#340)
* fix(windows): brand toast notifications with a tty7 AUMID (#339) * fix(windows): only write the toast shortcut where it is ours to write The AUMID shortcut was rewritten on every launch, which broke two cases the review caught on a real machine. An elevated install owns `%ProgramData%\...\tty7.lnk`, so writing a per-user copy listed "tty7" twice in the Start Menu and left an orphan pointing at a deleted exe once the uninstaller had removed only its own. And `cargo run` repointed the installed shortcut at `target\debug`, permanently, for anyone who both installs tty7 and builds it. So decide before writing. An all-users shortcut settles the question by itself — branded if the installer stamped our AUMID on it, otherwise we stay on the PowerShell identity, because the alternative is littering a Start Menu we cannot clean up. Otherwise we refresh the single per-user `tty7.lnk` Inno's default install owns anyway, and only when it is not already ours, and never from a cargo build directory. A dev build still brands the process for taskbar grouping, and still gets branded toasts when an install left a stamped shortcut behind — Windows asks that the AUMID be registered, not that it point at the process using it. Reading a shortcut back needs `IShellLinkW::GetPath`, hence the `Win32_Storage_FileSystem` feature; `SLGP_RAWPATH` keeps it from chasing a moved target over the network. Also close the window this opened. The shell indexes a new `.lnk` asynchronously and, for an AUMID it has not seen, `Toast::show()` reports success and drops the toast — measured, it does not return an error. A shortcut we wrote seconds ago is therefore not yet proof of anything, so toasts keep the PowerShell identity for half a minute after we write one: ugly beats invisible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
b7e08c7e11 |
feat(windows): add optional windows explorer context menus (#310)
* add CLI support for opening directories in new tabs f * feat(windows): add optional windows explorer context menus f * fix(gui): restore missing windows and reject lossy paths * fix(windows): harden explorer menu registration and native path handling * fix(cli): preserve native GUI paths on Windows --------- Co-authored-by: thomas <thomas@gmail.com> Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com> |
||
|
l0ng-ai
|
0c9f4baa3a |
fix(cli): make the PATH install reversible, honest, and safe to migrate
Follow-up on the review of #277. Seven fixes, no change to what the feature is for. An AppImage copy is now claimed with a marker file instead of being inferred from "am I an AppImage right now". Keying off the runtime meant that a user who moved from the AppImage to the tarball hit their own copy, read it as somebody else's binary, and never got another install for as long as that file sat there. The Windows uninstaller takes {app} back out of HKCU\Environment. Nothing did before: the entry is written by the app at runtime, so Inno never knew it existed and every uninstall grew the user's PATH by one dead entry. Unix has no equivalent hook and still leaves its symlink behind; that is now stated in the module docs rather than left to be discovered. An occupied candidate directory no longer ends the scan, and every platform now reports whether the install actually wins the lookup. `Occupied` on /opt/homebrew/bin used to mean giving up while ~/.local/bin sat free, and Windows — which appends to PATH and so never collides — reported `Installed` even when an existing tty7 earlier on PATH kept beating it. A new `InstalledShadowed` names the winner. `cargo run --release` no longer repoints the developer's real tty7 at a build tree. `cfg!(debug_assertions)` only covered the debug half of that. The Windows registry PATH is read, matched, and written as UTF-16 throughout. It went through `to_string_lossy` before, so a value the registry holds but Rust cannot represent as a String would have been written back with U+FFFD in place of its characters — the exact PATH corruption the surrounding code is careful to avoid. Two tests mutated $HOME and $PATH while the rest of the binary's tests ran beside them, and src/ui/home.rs mutates $HOME too. `candidate_dirs` takes home as a parameter, `place` takes its mode, and the PATH-joining and registry- joining rules are pure functions — so no test in this module touches the environment any more. 5 tests become 11, and the Windows joining logic is covered on every platform. Also: the config flag reaches Settings → About and both features docs instead of being config.json-only, startup reads config.json once instead of twice, and the CLI's strip failure warns like its sibling instead of being swallowed. |
||
|
l0ng-ai
|
c275960ceb |
feat(cli): ship the CLI in every installer and put it on PATH at launch
The `tty7` CLI was built by every release run and thrown away: all four bundle scripts copied only `tty7-app`, and the upload glob covers `dist/`, which the CLI never reached. Nothing put it on PATH either, so the agent-facing half of the product was unreachable from a shipped install. Bundle it on all four platforms, and have the GUI link it up itself rather than hiding the step behind a menu item most people never find. The install has two halves. The environment half prepends the CLI's directory to this process's PATH before the daemon is spawned, so every pane inherits it — that alone makes `tty7` work where agents actually run, writes nothing to disk, and behaves the same everywhere. The on-disk half symlinks into a directory already on PATH (Unix) or appends to HKCU\Environment (Windows), and is allowed to fail. Candidate directories are a fixed list intersected with PATH, not the first writable entry on it: pyenv/rbenv/asdf/mise shim directories sit at the front of PATH on many machines and are writable, and anything dropped there is deleted on the next rehash — silently, days later. Debug builds get the environment half only. `target/debug` holds a `tty7` too, so otherwise a `cargo run` would repoint the developer's real `tty7` at a debug binary, and each isolated dev-verify instance would rewrite the PATH of the machine it is meant to stay away from. |
||
|
l0ng-ai
|
3b68a42cb8 |
fix(installer): delete the pre-rename tty7.exe on upgrade
Builds before the tty7/tty7-app split installed the GUI as tty7.exe. Upgrading only adds tty7-app.exe, so the old binary stays on disk — and a taskbar pin, which Inno cannot rewrite the way it rewrites [Icons] shortcuts, still points at it. The user keeps launching the previous version from their pinned icon, against the same daemon endpoint as the new one. [InstallDelete] runs after PrepareToInstall has stopped the daemon and released the file lock, and before the new files land. A fresh install has nothing to remove. |
||
|
thomasandClaude Fable 5
|
10b6741368 |
refactor: rename the GUI binary to tty7-app, freeing tty7 for the CLI
The package name and every display name ("tty7" in menus, tray, .desktop
Name, CFBundleName, installer AppName, shortcuts) stay as they were; only
the executable file is now tty7-app / tty7-app.exe, per docs/cli-design.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014JPaaZVK7rfQPKyrymzsYv
|
||
|
l0ng-ai
|
208454e202 |
feat(remote): remote workspaces — a window that is one machine
Split the framework-free half of tty7 into `tty7-core` and add a headless
`tty7-server` built on it, so a workspace's filesystem, git and session state
can live on another machine while the GUI stays where it is.
- `crates/tty7-core`: wire protocol, session daemon, PTY, native SSH engine and
the domain model, with no gpui dependency. Module paths are unchanged.
- `crates/tty7-server`: the same daemon with no GUI attached, linked fully
static against musl and pushed onto the remote box. One dependency, on
purpose — a second one the GUI also needs belongs in core.
- `Host` trait + `HostId`/`HostRegistry`: every fs/git/watch call a workspace
makes goes through the machine it belongs to. `LocalHost` answers on this
box, `RemoteHost` over a routed control connection.
- `ui::host_ops`: the GUI's single door to a `Host`. Host calls block, so all
of them run on the background executor with the result landed on the UI
thread; de-duplication, staleness and error reporting live here rather than
at each call site. Enforced by a CI grep.
- Connect flow: home page → pick a configured SSH host → the machine's own
workspace list → a window bound to one workspace on it. Workspace switcher
groups by machine, this computer included.
- CI: static musl builds of `tty7-server` for x86_64/aarch64 via
cargo-zigbuild, a host-boundary grep, and version stamping factored out of
the nightly workflow. Both new jobs are non-required so branch protection
does not wedge open PRs.
Design and the interface contract it was built to are in
`docs/2026-07-27-remote-workspace-{design,impl-contract}.md`.
|
||
|
l0ng-ai
|
eb6c7ca3b3 |
fix(release): stop {tmp} from closing the Windows installer [Code] comment
The [Code] block comment used Pascal { } braces, but {tmp} inside it
closed the comment early, so ISCC parsed the trailing prose as code and
aborted with "'BEGIN' expected" — no Windows installer was produced.
Switch the comment to (* *) so brace-form constants stay literal.
|
||
|
|
90515d9fc3 |
fix(windows): stop the daemon before install/uninstall so it can replace tty7.exe (#72)
The persistent daemon (`tty7.exe --daemon`) is a detached background process
that outlives the GUI and is the running image of tty7.exe, so Windows locks
the file. An upgrade or uninstall then can't overwrite/remove the binary and
fails ("file in use" / reboot required) — the Restart Manager doesn't reliably
catch a no-window, DETACHED_PROCESS daemon in its own process group.
- spawn: extract the "stop the running daemon" half of `restart()` into a
reusable `stop()` (Shutdown -> await exit -> pid reap fallback -> clear
endpoint); `restart()` is now `stop()` + `ensure_running()`.
- main: add a `--stop-daemon` CLI entry that runs `stop()` and returns before
any GUI init, so it never opens a window.
- installer: in PrepareToInstall, extract the *new* tty7.exe to {tmp} and run
`--stop-daemon` (the new binary understands the flag; an old installed one
would launch the GUI instead), releasing the lock before file copy. Mirror it
in [UninstallRun]. Keep CloseApplications as a backstop but RestartApplications=no
(the GUI respawns the daemon on next start).
Co-authored-by: thomas <thomas@gmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
l0ng-ai
|
d0cf53522f |
feat(release): ship a Windows Inno Setup installer alongside the portable zip
bundle-windows.ps1 now compiles windows-installer.iss (ISCC is preinstalled on windows-latest) from the same staged payload as the zip, producing tty7-<version>-windows-x86_64-setup.exe: per-user install by default with an all-users option, Start Menu shortcut, Apps uninstall entry, optional desktop icon. Release workflow uploads the new artifact; READMEs and CHANGELOG updated. |