mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 16:02:24 +00:00
v26.9.0
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 webdev
|
edfea5b830 |
ci(macos): assert every Mach-O in the bundle is the arch it ships as (#687) (#692)
A macOS 26 user opened the Apple Silicon build and was told it "contains Intel parts" (#687). Downloading what is actually published — v26.8.2, v26.8.3 and the nightly after #605 — and reading every file's Mach-O header says otherwise: the three binaries under Contents/MacOS are thin arm64, nothing else in the bundle is Mach-O at all, and tty7-app's load commands are all /System/Library/Frameworks and /usr/lib. The build is right today. The likeliest reading of the warning is macOS pinning an x86_64 program someone ran in a pane on tty7.app as the responsible process — the same attribution bundle-macos.sh already documents for TCC — and that belongs on the issue, not in this change. What does belong here is that nothing would have caught it if the report had been right. assert-macho.sh knows how to say "this is a 64-bit Mach-O for <arch>, it links only what macOS ships, and it is signed", and since #605 it has said it — about the standalone tty7-server asset, and only that. It has never been pointed at anything inside the .app. A helper built without --target on an Intel runner, a dylib dragged in from /opt/homebrew, a universal binary from a toolchain that decided to be helpful: each would have zipped, notarized and shipped, and the first check would have been a user's Finder. So check the bundle, in bundle-macos.sh, where release.yml and nightly.yml both build it. After the signing block — assert-macho.sh insists on a signature, and this way one pass covers Developer ID and adhoc alike — and before the update zip and the DMG, so a bundle that fails never becomes an artifact, and before the `mv` that dissolves dist/tty7.app. First the binaries the script staged itself: tty7-app, tty7 and, when it is packaged, tty7-updater, each through assert-macho.sh at the full standard the server asset is held to. That also leaves every shipped binary's load commands in the release log, which is where the next report of this kind gets answered from. Then a sweep of every file in the bundle: `file` says which are Mach-O of any kind, `lipo -archs` names the slices in each, and the answer has to be exactly the matrix arch. Any other name is the wrong build; two names is a universal binary, which is what the report described. lipo judges rather than a parse of `file`'s prose because Apple's `file` and upstream libmagic word the arch differently and lipo's slice names do not move. A sweep that finds fewer Mach-Os than the binaries staged above fails as well, so a changed wording cannot quietly turn it into a no-op. On a Developer ID build this runs after notarization, which spends a few minutes of notary time on a bundle that was never going to ship. Cheap next to carrying a second copy of the block inside each signing branch. Deliberately not a fix for what the reporter saw, if it is the child-process attribution: no check at build time can speak for a binary the user runs inside a pane. What it guarantees is narrower and worth having — the bundle named arm64 contains nothing but arm64, and a release where that stops being true fails on the runner. Validated with bash -n and shellcheck, and by running the sweep — and the whole script in its adhoc posture — on Linux against fake bundles with file, lipo, otool, codesign, ditto and hdiutil stubbed: a clean bundle passes and packages; a wrong-arch updater, a universal tty7-app, a stray x86_64 dylib, an arm64e nested bundle and an empty bundle each fail and name the file, and nothing is zipped after a failure. Not yet run on a Mac; the next nightly is what answers that. |
||
  l0ng-aiandl0ng-ai
|
c216b389ae |
fix(macos): size the DMG ourselves, and stop blaming the runner's disk (#477)
The nightly channel has been frozen since 06:32 on 2026-08-10: every run dies in bundle-macos.sh with "hdiutil: create failed - No space left on device", on macos-15-intel, after the build, the signing and the notarization have all succeeded. The host disk was never full. #476 read that message as the runner running out of room and freed space for it; the `df -h` it added to prove the point disproved it instead — 105 GiB available, and the run failed anyway. The path in the error is under /Volumes/tty7, which is the image being created, not the runner: the volume ran out, not the disk. `hdiutil create -srcfolder` sizes the image from the bytes it is about to copy and does not cover what the filesystem spends carrying them, so a bundle that fits by measurement still runs the volume dry partway through the copy. It is a threshold rather than a cliff, which is why this began without anyone touching packaging: the binaries grew over edfadb7..fafcaa0, the x86_64 pair is the larger one and crossed it first, and arm64 kept building fine just underneath. Ask for the room explicitly — twice the content plus 64 MiB. The image is compressed on the way out, so the slack is nearly free: on a stage of this shape, 127 MiB of empty volume cost 672 KiB in the published DMG. Also drop #476's deletion of the build tree. It was paying for a problem that did not exist, and the bill was rust-cache finding nothing to save and every macOS build recompiling the dependency graph. The `mv` from that commit stays: a second full copy of the bundle is genuinely redundant, and nothing reads dist/tty7.app after this point. Verified locally against a staged bundle of the real shape (73 MiB, 101 files): the image is created, mounts with every file present, and detaches clean. The remaining unknown is only whether CI agrees, which the next nightly answers. Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com> |
||
|
l0ng-aiandl0ng-ai
|
05ed9fa4ff |
ci(macos): give the DMG somewhere to go on a runner that ran out of disk (#476)
Three nightlies in a row died in bundle-macos.sh with "hdiutil: create failed - No space left on device", across two different commits, always on macos-15-intel and never on arm64. The build, the signing and the notarization all succeed; the volume simply cannot hold the disk image on top of everything already staged on it. At `hdiutil create` the volume carries the whole release `target/` tree, the signed dist/tty7.app, the compressed update zip, a second full copy of the bundle under dist/dmg-stage, and the image being written. Two of those five are avoidable: Stage the bundle with `mv` instead of `cp -R`. Nothing reads dist/tty7.app after this point — the updater ships the zip, nightly.yml verifies that zip by extracting it elsewhere, and release.yml knows tty7.app only as an intermediate to keep out of the upload globs. Drop the build tree before the image is written. Every binary it produced is already inside the bundle and no later step in either workflow reads it. The cost is that rust-cache finds little left to save and the next macOS build recompiles the dependency graph — a slower nightly, against no nightly at all. `df -h` runs first so the next person to touch this has the number. Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com> |
||
 Gabiandl0ng-ai
|
e47b49dfdd |
fix(bundle): declare macOS TCC privacy keys for child processes (#323)
* fix(bundle): declare macOS TCC privacy keys for child processes tty7 currently ships no NS*UsageDescription keys and no data-access entitlements, so macOS falls back to a repeated "access other apps' data" prompt whenever a child process (shell, coding agent, mole, etc.) touches a protected folder such as ~/Library/Containers, Mail, Messages, or Calendar. kitty and Kaku both declare these privacy intents, which converts the prompt into a single, clear one-time grant. Add the folder/volume usage descriptions and the matching personal-information and device entitlements to the macOS bundle so the app behaves like its terminal peers. * fix(bundle): rework TCC usage strings per review - Correct problem statement: describe child-process-denied-without-prompt instead of the Full Disk Access framing (no NS*UsageDescription key exists for that class). - Add the full usage-string set (camera, microphone, contacts, calendars, reminders, photos, location, motion, local network, bluetooth, speech recognition, system administration, apple events), kitty-style wording. - Use macOS spellings: NSCalendarsFullAccessUsageDescription / NSRemindersFullAccessUsageDescription / NSLocationUsageDescription. - Drop every entitlement that has no matching usage string; keep only com.apple.security.automation.apple-events. - Restore trailing newline at EOF in bundle-macos.sh. - Document the Full Disk Access manual-grant requirement in docs/features.md. * docs: rewrite macOS privacy as feature notes (en + zh-CN) * fix(bundle): drop the apple-events entitlement, tidy the privacy docs The entitlement did not do what its comment claimed. Nothing in tty7 or in gpui's mac platform layer sends an Apple event, and it would not help the case this change is about either: the hardened-runtime automation check runs against the process actually sending the event, which is the pane's child carrying its own signature. What TCC reads off tty7.app is the usage string in Info.plist, which stays. Entitlements are per-executable and never inherited, so granting this one only widened what injected code could reach under an identity that already holds disable-library-validation. Docs: spell out the four Full Disk Access paths instead of running them together as one nested path, drop motion from the user-facing list (Core Motion has no macOS implementation, though the key stays for kitty parity), and place the section identically in the English and Chinese files. --------- 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>
|
||
 ayamir
|
a6754b28bc | feat(update): install verified macOS releases in app | ||
|
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. |
||
 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
|
22e1ab1694 |
tty7: a GPU-rendered, daemon-backed terminal in pure Rust
tty7 is split into two Rust processes: a persistent daemon that owns the shells and a GPU-rendered client that talks to it over a local socket. Because the shells live in the daemon, quitting and reopening the app leaves the session intact — detach and reattach, no tmux required. - Persistent sessions — the daemon holds the PTYs and child processes, so closing a window or swapping in a new build never takes a shell down. - Performance — an 11 MB `cat` completes in 95 ms and DOOM-fire renders at 888 fps; the daemon drains the PTY at device speed off the render path. - Shell-aware — new tabs and splits open in the current working directory; zsh, bash, fish, and PowerShell are set up automatically. - Enhanced prompt — inline completion, syntax highlighting, history, and in-terminal search, with rich flag/subcommand signatures for common tools. - Tabs, resizable splits, a command palette, click-to-open links, desktop notifications, eight themes, and CJK/IME input. Native builds for macOS, Windows, and Linux. Built on Zed's gpui and Alacritty's VT core. |