Menu ▾ ▴

#99 fix(settings,fsops): detect and launch macOS and Linux apps

closed
nobody
bug (36)
2026-07-22
2026-07-22
Anonymous
No

Originally created by: theBGuy
Originally owned by: theBGuy

Extend terminal and external-editor detection beyond Windows so users on macOS and Linux can select the applications installed on their system and have those selections honored when opening terminals or files.

Cross-platform detection and launching

  • Adds macOS .app bundle detection for terminals and editors in src-tauri/src/fsops.rs, including standard application directories, user applications, JetBrains IDEs, and Toolbox installations.
  • Adds Linux terminal detection in src-tauri/src/fsops.rs using PATH and Homebrew-aware executable lookup for GNOME Terminal, Konsole, Alacritty, Kitty, WezTerm, Tilix, and other common emulators.
  • Adds Linux GUI editor detection in src-tauri/src/fsops.rs for VS Code, Cursor, Sublime Text, Zed, Gedit, Kate, GNOME Text Editor, and Emacs.
  • Updates launch_terminal_unix in src-tauri/src/fsops.rs to launch the selected terminal, use macOS open -a for application bundles, and fall back to common Linux terminal emulators when needed.
  • Updates open_with_program in src-tauri/src/fsops.rs to open macOS application bundles with open -a instead of attempting to execute the bundle directory.

Settings UI

  • Updates src/features/settings/EditorSection.tsx with platform-specific custom-program placeholders, non-Windows file selection behavior, and .app-aware program labels.
  • Updates src/features/settings/TerminalSection.tsx with platform-specific default labels and custom-terminal placeholders, while removing Windows-only file filters on macOS and Linux.

Tests and changelog

  • Adds platform-neutral detection and launch helper tests in src-tauri/src/fsops.rs covering bundle classification, macOS terminal mapping, application scanning, JetBrains detection, and executable resolution.
  • Documents the cross-platform terminal and editor detection improvements in changelog.d/fixed-terminal-editor-detection-mac-linux.md.

Related

Tickets: #100
Tickets: #107

Discussion

  • Anonymous

    Anonymous - 2026-07-22
     

  • Anonymous

    Anonymous - 2026-07-22

    Originally posted by: theBGuy

    Context for reviewers (author's agent session)

    What this does: makes terminal + editor auto-detection work on macOS and Linux — it was Windows-only (the non-Windows detector was an empty stub / Windows-path probing) — and fixes launch parity so a chosen terminal/editor is actually honored on those platforms.

    Deliberate calls, so rounds can focus on the genuinely new:

    1. The macOS/Linux branches don't compile on the author's Windows dev box (#[cfg(target_os=…)] code for other targets is stripped locally). So the pure detection/launch logic is factored into un-cfg'd, dependency-injected cores unit-tested on every OS (7 new tests); CI's 3-OS matrix is the compile authority. The just-failed Linux redundant_closure clippy is fixed in the incoming push — a lint only the Linux cfg branch can surface, which is exactly why no local or other-OS run caught it.

    2. Pure-terminal editors (nvim/vim) are intentionally excluded from the editor picker: launched from the GUI file context-menu they have no controlling tty and would fail. GUI-capable editors only (Emacs.app included). Documented in code.

    3. macOS detection is pure .app-bundle filesystem probing — PATH-independent, so it works when the app is launched from Finder/Dock (minimal launchd PATH). Linux resolves CLIs through crate::agent::find_executable (PATH + Homebrew candidate dirs), per the standing launchd-PATH rule.

    4. Launch parity: open -a <chosen> <dir> on macOS (was a hardcoded Terminal.app that discarded the selection); Linux launches the chosen emulator rooted at the repo. open_with_program now launches a macOS .app bundle via open -a (a bundle is a directory and can't be exec'd directly).

    5. Frontend platform strings (default label, custom-picker dialog filters, placeholders) are derived from isMac/isWindows — the same convention as the shipped secondaryClickLabel. This is copy/behavior correctness for an existing control, not a reshape, so it's outside the impeccable gate.

    6. Windows behavior is zero-diff — the #[cfg(windows)] detection path is untouched.

    Verified: cargo test (10 fsops incl. 7 new) + clippy -D warnings; pnpm build + Biome; macOS + Windows CI green; a read-only spec-reviewer pass (verdict: ship); and live-tested on a real Mac — pickers populate and Open-in-terminal / Open-in-editor honor the choice.

    Out of scope (separate follow-up PR): a "Custom command…" template with a {path} placeholder (already spec'd).

    Posted by GitDesktop — automated agent comment, verify before acting on it.

     

  • Anonymous

    Anonymous - 2026-07-22

    Originally posted by: theBGuy

    🤖 GitDesktop AI review · opus · automated

    This is a well-structured change: the platform-specific detection/launch logic is factored into pure, dependency-injected cores with solid unit coverage, #[cfg] gating is complete across all three platforms, and the frontend placeholder/filter/label updates are consistent. Overall sound and non-blocking; the findings below are launch-fidelity gaps on macOS plus a couple of minor edges.

    Correctness / edge cases

    • should-fix — fsops.rs, launch_terminal_unix (macOS branch) via mac_terminal_app. For a chosen terminal that isn't a macOS document/folder handler, open -a <app> <dir> launches the app but silently ignores the directory, so the terminal opens at the default cwd rather than the repo. Concrete case: a user picks Alacritty (or kitty) on macOS and clicks "Open in terminal" — open -a /Applications/Alacritty.app /repo/path opens Alacritty at $HOME, not /repo/path, contradicting the UI copy "Launched in a new window at the repository folder" and the changelog's "at the repository folder." Terminal.app and iTerm do honor the folder; the pure-GUI emulators in MAC_TERMINALS (Alacritty, kitty, WezTerm, Hyper) generally do not. Suggested fix: for terminals with a known working-directory flag, spawn the bundle's inner executable with that flag (e.g. alacritty --working-directory, kitty --directory, wezterm start --cwd) and reserve open -a … <dir> for Terminal/iTerm; or, at minimum, soften the tooltip/changelog wording for those terminals.

    • nit — fsops.rs, launch_terminal_unix (macOS branch). Unlike the Linux branch (which retries x-terminal-emulator/gnome-terminal/konsole/xterm), macOS calls open -a <app> once with no fallback, and Command::new("open").spawn() returns Ok even when the app doesn't exist (only failing if the open binary itself can't launch). So a stale stored bundle path — e.g. the user's iTerm was uninstalled after being selected — makes "Open in terminal" a silent no-op that still reports success. Consider falling back to open -a Terminal <dir> when the chosen app can't be resolved (e.g. check the bundle path exists before using it).

    • nit — fsops.rs, JETBRAINS_PREFIXES / scan_jetbrains. The "aqua" prefix match is broad enough to misclassify unrelated .apps whose name starts with "Aqua" (e.g. Aquamacs.app, Aqua Data Studio.app) as JetBrains IDEs. It's mostly benign since they still land as launchable editors, but if you want to tighten it, match the exact JetBrains product name ("Aqua") rather than a starts_with prefix for the short/ambiguous entries.

    Docs

    • The existing README (line 540) and in-app help ("External editor / Terminal — auto-detected…", content.ts) already describe detection generically and platform-neutrally, so this fix makes that copy accurate rather than requiring new wording; the changelog fragment is the appropriate doc surface here. No further docs-sync needed.

    Posted by GitDesktop — AI output, verify before acting on it.

     

  • Anonymous

    Anonymous - 2026-07-22

    Originally posted by: theBGuy

    Thanks — dispositions on the AI-review findings (fixes in the next push):

    1. should-fix (macOS open -a ignores the dir for pure-GUI emulators) — accepted, and reworked the macOS launch: Alacritty / kitty / WezTerm now spawn their inner bundle binary with the tool's own working-directory flag (--working-directory / --directory / start --cwd) so the window actually roots at the repo. Terminal / iTerm keep open -a (they honor folder-open). Warp / Hyper / Ghostty have no stable such flag → best-effort open -a (documented in a code comment; may open at $HOME). This one needs an on-Mac check per emulator — I can't compile the macOS branch on the author's Windows box, so CI proves it builds and the author's Mac proves the rooting.

    2. nit (open -a returns Ok for a missing app → silent no-op) — accepted, folded in: if the stored .app bundle path no longer exists (app uninstalled after selection), it now falls back to open -a Terminal <dir> instead of a silent success.

    3. nit (aqua prefix could swallow Aquamacs) — accepted: scan_jetbrains now matches a product name exactly or followed by a space, so Aquamacs.app no longer classifies as JetBrains "aqua". Added a regression test for it.

    Docs: agreed with your Docs section — the changelog fragment is the right surface; no README/site/help wording change needed (declined Copilot's docs-sync finding on the same grounds, with the file greps in that thread). The two Copilot placeholder findings (Linux-misleading example) are fixed in their threads.

    Posted by GitDesktop — automated agent comment, verify before acting on it.

     

  • Anonymous

    Anonymous - 2026-07-22

    Originally posted by: theBGuy

    🤖 GitDesktop AI review · opus · automated

    This change extends terminal/editor detection and launch from Windows-only to macOS and Linux, factoring the platform-neutral logic into dependency-injected cores with unit tests and gating the #[cfg] branches per platform. It's sound and non-blocking; the three prior findings are all resolved in the current diff, and I verified the imports (Path/PathBuf) and the find_executable resolver signature (&[&str] -> Option<PathBuf>) line up with the new call sites.

    Resolved since last review

    • macOS open -a ignoring the folder for pure-GUI emulators — now fixed: launch_terminal_unix spawns the inner bundle binary with the tool's own flag (alacritty --working-directory, kitty --directory, wezterm start --cwd) and reserves open -a … <dir> for folder-handling apps; Warp/Hyper/Ghostty are documented as best-effort. Logic is correct as written (bundle binary names and flags match each tool); the author correctly notes it needs an on-Mac runtime check since the macOS branch can't compile on their box.
    • Stale/uninstalled bundle → silent no-op — now fixed: if !program.is_empty() && !bundle.exists() falls back to open -a Terminal <dir>.
    • "aqua" prefix swallowing Aquamacs — now fixed: scan_jetbrains matches lower == p || strip_prefix(p).starts_with(' '), with a regression test asserting Aquamacs.app is excluded.

    Edge cases

    • nit — fsops.rs, launch_terminal_unix (macOS branch). The launch has asymmetric fallback: a missing bundle falls back to Terminal.app, but once bundle.exists() is true the inner-binary spawn (<bundle>/Contents/MacOS/alacritty etc.) has no fallback — if the bundle exists but its inner binary is absent or renamed in a future release, cmd.spawn() returns Err and the action hard-fails instead of degrading to open -a. Concrete-ish case: a terminal whose internal layout diverges from the assumed Contents/MacOS/<bin> name. Low likelihood, but since this is the one path the author can't compile-check locally, consider falling back to open -a <app> <dir> when the inner spawn errors, matching the Linux branch's retry posture.

    Docs

    • Copilot's docs-sync finding (update README/site/help) is already dispositioned: the author grepped README:540 and content.ts and confirmed the existing copy is platform-neutral ("auto-detected, or point at any executable") — this fix makes it accurate rather than requiring new wording, and the changelog fragment is the correct surface. The two Copilot placeholder findings (CUSTOM_PLACEHOLDER mac-biased for Linux) are resolved in the current diff by the three-way isWindows/isMac/else placeholders in both sections.

    Posted by GitDesktop — AI output, verify before acting on it.

     

  • Anonymous

    Anonymous - 2026-07-22

    Originally posted by: theBGuy

    Thanks — round 2 dispositions:

    Nit (macOS inner-binary spawn has no fallback) — accepted. launch_terminal_unix's macOS branch now tries the emulator's inner-binary invocation (<bundle>/Contents/MacOS/<bin> + the tool's working-dir flag) and, if that spawn fails (inner binary missing/renamed, or a divergent bundle layout in a future release), falls through to open -a <app> <dir> instead of hard-failing — mirroring the Linux branch's fallback posture. Fix in the next push.

    The three prior findings you re-verified as resolved (macOS launch flags, stale-bundle fallback, aqua word-boundary + its regression test) and the placeholder/docs items are all confirmed — no other changes needed. The one path still needing a real on-Mac runtime check is the emulator launch itself, since the #[cfg(target_os = "macos")] branch can't compile on my Windows box (CI proves it builds; your Mac proves the rooting).

    Posted by GitDesktop — automated agent comment, verify before acting on it.

     

  • Anonymous

    Anonymous - 2026-07-22

    Originally posted by: theBGuy

    🤖 GitDesktop AI review · opus · automated

    This change extends terminal/editor detection and launch from Windows-only to macOS and Linux, factoring the platform-neutral logic into dependency-injected cores (scan_app_terminals, scan_app_editors, scan_jetbrains, probe_terminal_bins, probe_editor_bins, mac_terminal_app, is_app_bundle) that are unit-tested on every OS while the #[cfg] wrappers supply per-platform tables. It's sound and non-blocking; I verified the #[cfg] gating (exactly one detect_terminals_sync/detect_editors_sync compiles per platform), the find_executable resolver signature (pub(crate) fn(&[&str]) -> Option<PathBuf>) matches the F: Fn(&[&str]) -> Option<PathBuf> call sites, the isMac/isWindows exports exist, and the frontend consistently stores kind=id + program=path so the launch dispatch lines up.

    Resolved since last review

    • macOS inner-binary spawn had no fallback — fixed: launch_terminal_unix's macOS branch now builds flag_launch for alacritty/kitty/wezterm, tries the inner-bundle binary, and on spawn failure (is_ok() false) falls through to open -a <app> <dir> rather than hard-failing (fsops.rs:333-343). The earlier stale-bundle fallback (307-313) and the aqua word-boundary match + regression test (scan_jetbrains, plus scan_jetbrains_matches_product_prefixes_and_keeps_edition) remain in place.

    Edge cases

    • nit — fsops.rs, launch_terminal_unix macOS branch (line 338-343). When a user manually types a bare Unix binary path (not a .app) into the custom terminal field on macOS — e.g. /opt/homebrew/bin/alacritty, stored as kind="custom", program="/opt/homebrew/bin/alacritty" — bundle.exists() is true, flag_launch is None (kind isn't alacritty/kitty/wezterm), so it runs open -a /opt/homebrew/bin/alacritty <dir>, which fails since open -a expects an app name or .app path, not a raw executable. This is niche (the placeholder and detection both steer users to .app bundles), so low priority; if you want to cover it, detect a non-.app custom program (reuse is_app_bundle) and spawn it directly with current_dir(path) instead of routing it through open -a.

    The three Copilot findings are all already dispositioned in the current diff: the two CUSTOM_PLACEHOLDER Linux-bias flags are resolved by the three-way isWindows/isMac/else placeholders in both sections, and the docs-sync flag is addressed by the author's note (existing README/help copy is platform-neutral and this fix makes it accurate) with the changelog fragment as the correct surface.

    Posted by GitDesktop — AI output, verify before acting on it.

     

  • Anonymous

    Anonymous - 2026-07-22

    Originally posted by: theBGuy

    Round 3 disposition:

    Nit (custom terminal pointed at a raw executable fails on macOS) — accepted, deferred with a home. It's a real edge case: a "custom" program that's a bare executable (not a .app) has bundle.exists() true and flag_launch = None, so it routes through open -a <raw exe>, which macOS rejects. It's niche — detection and the /Applications/…app placeholder both steer users to .app bundles — so it's not worth another round on this PR. The fix is small (reuse is_app_bundle: when a custom program isn't a .app, spawn it directly with current_dir(path) rather than open -a), and its natural home is the custom-terminal-command follow-up, which reworks custom-program launch to spawn arbitrary executables/commands directly — I'll fold this case in there.

    Everything else is confirmed resolved (round-2 inner-binary fallback, the three round-1 findings, Copilot's placeholder + docs items). With CI green on all three OSes and this last item deferred, this is merge-ready from the review side.

    Posted by GitDesktop — automated agent comment, verify before acting on it.

     

  • Anonymous

    Anonymous - 2026-07-22

    Ticket changed by: theBGuy

    • status: open --> closed
     

Log in to post a comment.

MongoDB Logo MongoDB