Repository navigation
Fix zsh git branch refresh race after cwd change - #71
Merged
Merged
Conversation
Contributor
Older manaflow preview screenshots (latest comment is below)Preview Videos and ScreenshotsOpen Workspace (1 hr expiry) · Open Dev Browser (1 hr expiry) · Open Diff Heatmap Screenshot capture was skipped.
Generated by manaflow preview system |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Older manaflow preview screenshots (latest comment is below)Preview Videos and Screenshots⏳ Preview screenshots are being captured... Workspace and dev browser links will appear here once the preview environment is ready. Generated by manaflow preview system |
…branches-not-autoshow
Contributor
Older manaflow preview screenshots (latest comment is below)Preview Videos and ScreenshotsOpen Workspace (1 hr expiry) · Open Dev Browser (1 hr expiry) · Open Diff Heatmap Screenshot capture was skipped.
Generated by manaflow preview system |
Fixes build failure when compiling Metal shaders for iOS xcframework targets — the self-hosted runner needs `xcodebuild -downloadComponent MetalToolchain` installed before `xcrun metal` can run. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Contributor
Preview Videos and ScreenshotsOpen Workspace (1 hr expiry) · Open Dev Browser (1 hr expiry) · Open Diff Heatmap Screenshot capture was skipped.
Generated by manaflow preview system |
bn-l
pushed a commit
to bn-l/cmux
that referenced
this pull request
Apr 3, 2026
* Fix zsh git branch refresh race after cwd change * Clarify intentional duplicate cwd check in git refresh path * Add Metal Toolchain download step to CI and release workflows Fixes build failure when compiling Metal shaders for iOS xcframework targets — the self-hosted runner needs `xcodebuild -downloadComponent MetalToolchain` installed before `xcrun metal` can run. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
3 tasks
WrangleMeThis
added a commit
to agiterra/cmux
that referenced
this pull request
May 18, 2026
* agiterra: surface.set_background socket method
Bridges Ghostty's runtime background-image config to a per-surface socket
call so crew themes can set theme.json backgrounds without bouncing the app.
Net-new logic in two extension files matching the existing fork pattern:
- Sources/GhosttyApp+BackgroundImage.swift — applies inline overrides via
ghostty_config_load_string + ghostty_surface_update_config (no refactor
of loadDefaultConfigFilesWithLegacyFallback needed)
- Sources/TerminalController+BackgroundImage.swift — v2 handler that
parses params, validates fit/position/opacity, resolves the surface,
and dispatches through
Shared-file edits in TerminalController.swift are 3 lines, all tagged
// AGITERRA-BG: per-surface bg image so `git grep AGITERRA-BG` finds
every fork touchpoint during upstream merges:
- new switch case for surface.set_background (2 lines)
- capabilities list entry (1 line)
API: surface.set_background {image, opacity, fit, position, repeat, clear}
with absolute-path requirement; clear=true resets the surface.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(bg): wake cold surface on v2SurfaceSetBackground
v2SurfaceSetBackground errored with surface_unavailable when the target
surface had no live Ghostty surface yet (freshly created split,
backgrounded workspace not user-selected). Clients (crew-tools) silently
caught the error and the themed pane stayed blank.
Calls requestBackgroundSurfaceStartIfNeeded — the same API used by
input-recovery / focus paths — so the lazy surface gets nudged into
existence. Clients still see surface_unavailable on the first call but
the data payload now includes "instantiation": "requested" so they know
a retry will succeed once the surface comes up.
Combined with crew-tools PR manaflow-ai#71 (waitForPty poll) the round-trip is:
call 1 → cold → returns err + kicks off instantiation
poll for PTY (crew-tools)
call 2 → live → applies bg
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
austinywang
added a commit
that referenced
this pull request
Jun 5, 2026
Addresses codex/greptile review of the link fix: under mouse reporting a Cmd-click over a link still leaked a half-click to the program because mouseButtonCallback reported the press (link-open runs only on release). The ghostty follow-up (manaflow-ai/ghostty#74) suppresses the whole click — press and release — whenever the ctrl/super link chord is held, keyed on the modifier like the existing shift-release path so cursor jitter can't leak a press or a release. Eliminates the half-click in both directions. Re-pins the ghostty submodule from 55d154a to d1dbbec, repoints the prebuilt GhosttyKit release/checksum, and updates docs/ghostty-fork.md. d1dbbec is an ancestor of manaflow-ai/ghostty main (PR #71 and #74 merged). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
austinywang
added a commit
that referenced
this pull request
Jun 5, 2026
…d links Final review iteration (codex P2). After #74 suppressed the press/release of a ctrl/super-chord link click, cursorPosCallback could still emit .motion reports during a Cmd-held drag (click_state == .press), leaking button-motion to a mouse-grabbing program. ghostty #75 mirrors the shift "grab override" for the ctrl/super chord in the motion path, so the link chord now suppresses the whole click+drag — press, release, and motion — consistently. Re-pins the ghostty submodule from d1dbbec to 76ead3e and repoints the prebuilt GhosttyKit release/checksum + docs. 76ead3e is an ancestor of manaflow-ai/ghostty main (PR #71, #74, #75 merged). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
austinywang
added a commit
that referenced
this pull request
Jun 5, 2026
Final review iteration (codex P2 x2). After #74/#75 suppressed the whole click+ drag for the ctrl/super link chord, two edges remained: the suppression fired for any button (swallowing ctrl/super right/middle clicks instead of delivering them to the program), and a stale link highlight/cursor could persist when the chord was released through cursorPosCallback's mods. ghostty #76 scopes the suppression to the left button and clears the hover by refreshing when over_link is set (mirroring keyCallback's existing reset branch). Re-pins the ghostty submodule from 76ead3e to f241952 and repoints the prebuilt GhosttyKit release/checksum + docs. f241952 is an ancestor of manaflow-ai/ghostty main (PR #71, #74, #75, #76 merged). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
austinywang
added a commit
that referenced
this pull request
Jun 10, 2026
…ex) (#5406) * Bump ghostty to 55d154a: open links on cmd-click under mouse reporting Fixes #5128. Clicking a link inside a fullscreen alternate-screen TUI (Claude Code, Codex) opened the OS default browser instead of honoring the configured cmux link-open target. cmux's GHOSTTY_ACTION_OPEN_URL handler is already mode-independent (resolveTerminalOpenURLTarget routes per BrowserAvailabilitySettings, no mouse-mode branch); the gap was in ghostty core, where link hover state was refreshed only when mouse reporting was off or shift released capture, so a Cmd-click under a mouse-grabbing TUI never fired open_url. Bumps the ghostty submodule to 55d154a (previous pin 176bd55 + the two link-fix commits from manaflow-ai/ghostty#71, merged into fork main). The fix also evaluates links locally when the ctrl/super link modifier is held, using the effective mouse-reporting state, matching iTerm2 and macOS Terminal. Publishes and pins the matching GhosttyKit xcframework (xcframework-55d154a...-crashsubdir-cmux-crash-v1) and updates docs/ghostty-fork.md. No cmux Swift change is required (no cmux-only gap), so there are no new user-facing strings to localize. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Re-pin ghostty to d1dbbec: suppress half-click leak on cmd-clicked links Addresses codex/greptile review of the link fix: under mouse reporting a Cmd-click over a link still leaked a half-click to the program because mouseButtonCallback reported the press (link-open runs only on release). The ghostty follow-up (manaflow-ai/ghostty#74) suppresses the whole click — press and release — whenever the ctrl/super link chord is held, keyed on the modifier like the existing shift-release path so cursor jitter can't leak a press or a release. Eliminates the half-click in both directions. Re-pins the ghostty submodule from 55d154a to d1dbbec, repoints the prebuilt GhosttyKit release/checksum, and updates docs/ghostty-fork.md. d1dbbec is an ancestor of manaflow-ai/ghostty main (PR #71 and #74 merged). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Re-pin ghostty to 76ead3e: full click+drag suppression for cmd-clicked links Final review iteration (codex P2). After #74 suppressed the press/release of a ctrl/super-chord link click, cursorPosCallback could still emit .motion reports during a Cmd-held drag (click_state == .press), leaking button-motion to a mouse-grabbing program. ghostty #75 mirrors the shift "grab override" for the ctrl/super chord in the motion path, so the link chord now suppresses the whole click+drag — press, release, and motion — consistently. Re-pins the ghostty submodule from d1dbbec to 76ead3e and repoints the prebuilt GhosttyKit release/checksum + docs. 76ead3e is an ancestor of manaflow-ai/ghostty main (PR #71, #74, #75 merged). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Re-pin ghostty to f241952: scope link suppression + clear stale hover Final review iteration (codex P2 x2). After #74/#75 suppressed the whole click+ drag for the ctrl/super link chord, two edges remained: the suppression fired for any button (swallowing ctrl/super right/middle clicks instead of delivering them to the program), and a stale link highlight/cursor could persist when the chord was released through cursorPosCallback's mods. ghostty #76 scopes the suppression to the left button and clears the hover by refreshing when over_link is set (mirroring keyCallback's existing reset branch). Re-pins the ghostty submodule from 76ead3e to f241952 and repoints the prebuilt GhosttyKit release/checksum + docs. f241952 is an ancestor of manaflow-ai/ghostty main (PR #71, #74, #75, #76 merged). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Re-pin ghostty to 59fb750: clear link-click latch unconditionally Addresses the final review round on the link-under-mouse-reporting fix: - codex P2: the suppression re-checked live modifiers, so releasing ctrl/super before the mouse button could leak the release. ghostty #77 latches the decision at left-button press (mouse.link_click_active) and applies it through the release. - greptile P2: the latch was cleared only inside the mouse-reporting block, so toggling reporting off mid-click could leave it stale; it is now cleared unconditionally on left release. Re-pins the ghostty submodule from f241952 to 59fb750 and repoints the prebuilt GhosttyKit release/checksum + docs. 59fb750 is an ancestor of manaflow-ai/ghostty main once #77 merges. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Re-pin ghostty to 9f014e9: unify link-click suppression and open Final review round on the link-under-mouse-reporting fix (codex P2/P3): the report-suppression latched at press but the link-open path re-derived from live modifiers, so releasing ctrl/super before the button swallowed the click, and the latch reset wasn't reached on the link-open early return. ghostty #78 makes linkAtPos use the latched chord and attempts processLinks whenever the click is latched, and clears the latch via a function-level defer. One press-time decision now drives press/drag/release suppression and link opening. Re-pins the ghostty submodule from 59fb750 to 9f014e9 and repoints the prebuilt GhosttyKit release/checksum + docs. 9f014e9 is an ancestor of manaflow-ai/ghostty main once #78 merges. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Re-pin ghostty to df789cd: only open latched link clicks that started on a link Final review round (codex): the latched link-open path opened the link under the release cursor for any in-flight ctrl/super click, so a chord drag that started off a link and released over one opened that link (its press was suppressed). ghostty #79 captures whether the press was over a link (link_press_over_link) and only opens via the latched path when it was, so an off-link-started drag is swallowed rather than opening a link it merely released over. Re-pins the ghostty submodule from 9f014e9 to df789cd and repoints the prebuilt GhosttyKit release/checksum + docs. df789cd is an ancestor of manaflow-ai/ghostty main once #79 merges. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix: pin merged GhosttyKit artifact * Pin GhosttyKit checksum for merged ghostty 34cbf18 (#5128 + #5458) Pins the SHA256 of the published prebuilt xcframework-34cbf180d8917b802d61d9929cfb493594f2ab52-crashsubdir-cmux-crash-v1 that merges the surface registry serialization (#5458) into the alt-screen Cmd-click link fix (#5128). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Refresh Swift file-length budget for ContentView/SessionIndexView The origin/main merge (sidebar scroll + macOS 27 crash fixes, PR #5670) grew Sources/ContentView.swift to 19161 and Sources/SessionIndexView.swift to 2877, which exceed the inherited budget. Bump only those two entries to match; this is upstream main debt surfaced by the merge, not a change from the ghostty bump. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
lawrencecchen
added a commit
that referenced
this pull request
Oct 2, 2026
closing_one_hundred_terminals_updates_the_tree_at_once_and_ends_every_host stalls about 2 s at fixed points (closes #71, #72, #88, #99 in probe runs 36951324179, 36953259790, 36953266201, 36951369512; it also did so before the host frame reader landed). Daemon probes showed each stall is a SetKittyGraphicsLimits request on a mux-deadline worker that waits the full 2 s CONTROL_RESPONSE_TIMEOUT and fails, at Kitty budget bucket changes. The terminal's reader received ResyncRequired for every update and never the KittyGraphicsLimitsAck. The request holds the terminal's runtime lock while it waits, so a close of that terminal waits too. Reproduced locally with the hosted binary: closing 17 terminals stalls one close for about 2.0 s in 3 of 3 runs (bucket 32 -> 8). The test closes 17 terminals and requires every close-terminal reply under 1 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
lawrencecchen
added a commit
that referenced
this pull request
Oct 2, 2026
closing_one_hundred_terminals_updates_the_tree_at_once_and_ends_every_host stalls about 2 s at fixed points (closes #71, #72, #88, #99 in probe runs 36951324179, 36953259790, 36953266201, 36951369512; it also did so before the host frame reader landed). Daemon probes showed each stall is a SetKittyGraphicsLimits request on a mux-deadline worker that waits the full 2 s CONTROL_RESPONSE_TIMEOUT and fails, at Kitty budget bucket changes. The terminal's reader received ResyncRequired for every update and never the KittyGraphicsLimitsAck. The request holds the terminal's runtime lock while it waits, so a close of that terminal waits too. Reproduced locally with the hosted binary: closing 17 terminals stalls one close for about 2.0 s in 3 of 3 runs (bucket 32 -> 8). The test closes 17 terminals and requires every close-terminal reply under 1 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
lawrencecchen
added a commit
that referenced
this pull request
Oct 2, 2026
closing_one_hundred_terminals_updates_the_tree_at_once_and_ends_every_host stalls about 2 s at fixed points (closes #71, #72, #88, #99 in probe runs 36951324179, 36953259790, 36953266201, 36951369512; it also did so before the host frame reader landed). Daemon probes showed each stall is a SetKittyGraphicsLimits request on a mux-deadline worker that waits the full 2 s CONTROL_RESPONSE_TIMEOUT and fails, at Kitty budget bucket changes. The terminal's reader received ResyncRequired for every update and never the KittyGraphicsLimitsAck. The request holds the terminal's runtime lock while it waits, so a close of that terminal waits too. Reproduced locally with the hosted binary: closing 17 terminals stalls one close for about 2.0 s in 3 of 3 runs (bucket 32 -> 8). The test closes 17 terminals and requires every close-terminal reply under 1 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
lawrencecchen
added a commit
that referenced
this pull request
Oct 2, 2026
closing_one_hundred_terminals_updates_the_tree_at_once_and_ends_every_host stalls about 2 s at fixed points (closes #71, #72, #88, #99 in probe runs 36951324179, 36953259790, 36953266201, 36951369512; it also did so before the host frame reader landed). Daemon probes showed each stall is a SetKittyGraphicsLimits request on a mux-deadline worker that waits the full 2 s CONTROL_RESPONSE_TIMEOUT and fails, at Kitty budget bucket changes. The terminal's reader received ResyncRequired for every update and never the KittyGraphicsLimitsAck. The request holds the terminal's runtime lock while it waits, so a close of that terminal waits too. Reproduced locally with the hosted binary: closing 17 terminals stalls one close for about 2.0 s in 3 of 3 runs (bucket 32 -> 8). The test closes 17 terminals and requires every close-terminal reply under 1 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
lawrencecchen
added a commit
that referenced
this pull request
Oct 2, 2026
closing_one_hundred_terminals_updates_the_tree_at_once_and_ends_every_host stalls about 2 s at fixed points (closes #71, #72, #88, #99 in probe runs 36951324179, 36953259790, 36953266201, 36951369512; it also did so before the host frame reader landed). Daemon probes showed each stall is a SetKittyGraphicsLimits request on a mux-deadline worker that waits the full 2 s CONTROL_RESPONSE_TIMEOUT and fails, at Kitty budget bucket changes. The terminal's reader received ResyncRequired for every update and never the KittyGraphicsLimitsAck. The request holds the terminal's runtime lock while it waits, so a close of that terminal waits too. Reproduced locally with the hosted binary: closing 17 terminals stalls one close for about 2.0 s in 3 of 3 runs (bucket 32 -> 8). The test closes 17 terminals and requires every close-terminal reply under 1 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
lawrencecchen
added a commit
that referenced
this pull request
Oct 2, 2026
closing_one_hundred_terminals_updates_the_tree_at_once_and_ends_every_host stalls about 2 s at fixed points (closes #71, #72, #88, #99 in probe runs 36951324179, 36953259790, 36953266201, 36951369512; it also did so before the host frame reader landed). Daemon probes showed each stall is a SetKittyGraphicsLimits request on a mux-deadline worker that waits the full 2 s CONTROL_RESPONSE_TIMEOUT and fails, at Kitty budget bucket changes. The terminal's reader received ResyncRequired for every update and never the KittyGraphicsLimitsAck. The request holds the terminal's runtime lock while it waits, so a close of that terminal waits too. Reproduced locally with the hosted binary: closing 17 terminals stalls one close for about 2.0 s in 3 of 3 runs (bucket 32 -> 8). The test closes 17 terminals and requires every close-terminal reply under 1 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
lawrencecchen
added a commit
that referenced
this pull request
Oct 2, 2026
closing_one_hundred_terminals_updates_the_tree_at_once_and_ends_every_host stalls about 2 s at fixed points (closes #71, #72, #88, #99 in probe runs 36951324179, 36953259790, 36953266201, 36951369512; it also did so before the host frame reader landed). Daemon probes showed each stall is a SetKittyGraphicsLimits request on a mux-deadline worker that waits the full 2 s CONTROL_RESPONSE_TIMEOUT and fails, at Kitty budget bucket changes. The terminal's reader received ResyncRequired for every update and never the KittyGraphicsLimitsAck. The request holds the terminal's runtime lock while it waits, so a close of that terminal waits too. Reproduced locally with the hosted binary: closing 17 terminals stalls one close for about 2.0 s in 3 of 3 runs (bucket 32 -> 8). The test closes 17 terminals and requires every close-terminal reply under 1 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
lawrencecchen
added a commit
that referenced
this pull request
Oct 2, 2026
closing_one_hundred_terminals_updates_the_tree_at_once_and_ends_every_host stalls about 2 s at fixed points (closes #71, #72, #88, #99 in probe runs 36951324179, 36953259790, 36953266201, 36951369512; it also did so before the host frame reader landed). Daemon probes showed each stall is a SetKittyGraphicsLimits request on a mux-deadline worker that waits the full 2 s CONTROL_RESPONSE_TIMEOUT and fails, at Kitty budget bucket changes. The terminal's reader received ResyncRequired for every update and never the KittyGraphicsLimitsAck. The request holds the terminal's runtime lock while it waits, so a close of that terminal waits too. Reproduced locally with the hosted binary: closing 17 terminals stalls one close for about 2.0 s in 3 of 3 runs (bucket 32 -> 8). The test closes 17 terminals and requires every close-terminal reply under 1 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
lawrencecchen
added a commit
that referenced
this pull request
Oct 2, 2026
closing_one_hundred_terminals_updates_the_tree_at_once_and_ends_every_host stalls about 2 s at fixed points (closes #71, #72, #88, #99 in probe runs 36951324179, 36953259790, 36953266201, 36951369512; it also did so before the host frame reader landed). Daemon probes showed each stall is a SetKittyGraphicsLimits request on a mux-deadline worker that waits the full 2 s CONTROL_RESPONSE_TIMEOUT and fails, at Kitty budget bucket changes. The terminal's reader received ResyncRequired for every update and never the KittyGraphicsLimitsAck. The request holds the terminal's runtime lock while it waits, so a close of that terminal waits too. Reproduced locally with the hosted binary: closing 17 terminals stalls one close for about 2.0 s in 3 of 3 runs (bucket 32 -> 8). The test closes 17 terminals and requires every close-terminal reply under 1 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.