Hey, thanks for the PR!

Maybe it also makes sense to default to git-bash exe if it exists on the system? see #44

Thanks! Just pushed b521537 on top — default_shell() now walks: $SHELL → Git for Windows bash.exe (env-resolved %ProgramFiles%, %ProgramFiles(x86)%, %ProgramW6432%, %LOCALAPPDATA%\Programs, then PATH) → %COMSPEC% → cmd.exe.

Verified on Windows 11 — with Git installed it now spawns "C:\Program Files\Git/bin/bash.exe" as the PTY child; without Git it falls back to cmd.exe (from the earlier commit). Lets me know if you'd prefer a tighter detection (e.g. only %ProgramFiles%\Git\bin\bash.exe) or a different fallback order.

Investigated the RGP examples on Windows next — wanted to flag what I found before scope-creeping this PR.

TL;DR: the path-/payload-handling code in inline.rs / model.rs is fine on Windows. The 3D rat cursor renders correctly via the same code path the examples use. The actual blocker for big_rat / draw / document is ConPTY stripping APC sequences before they reach the host, which means inline::consume_pty_output never sees the \x1b_ratty;…\x1b\ register/place sequences that the widget writes to stdout.

How I confirmed it: wrote a tiny portable-pty-backed probe that spawns a child running printf '\x1b_PROBE;hello=world\x1b\', then dumps every byte received from the PTY master:

=== PROBE RESULT (default ConPTY flags) ===
Total bytes read: 16
0000: 1b 5b 3f 39 30 30 31 68 1b 5b 3f 31 30 30 34 68    .[?9001h.[?1004h

Contains \x1b_ (APC start)?  false
Contains 'PROBE;' marker?    false

Only the bash-init CSIs survive — the APC body and ST terminator are dropped by conhost. (Same outcome when running big_rat inside Ratty with RUST_LOG=warn: the cursor model loads from the embedded GLB, but no registered RGP object / failed to load RGP object line ever appears, because the register APC never makes it to inline::handle_rgp_sequence.)

The fix lives upstream in portable-pty. Microsoft added PSEUDOCONSOLE_PASSTHROUGH_MODE (0x8) for exactly this use case (Windows 11 22H2+ / Windows Server 2025). The flag is even already declared in pty/src/win/psuedocon.rs as #[allow(dead_code)] — it just isn't OR'd into the CreatePseudoConsole call. Until portable-pty exposes it (env-var override or a builder option), Ratty (and any other terminal built on portable-pty) can't see APC traffic on Windows.

Proposed path forward:

1. Merge this PR as-is — it unblocks Windows for everyone hitting Wont Open on Windows #44 and matches your suggestion to default to Git Bash. RGP support is independent of the shell-default work and shouldn't gate this one.
2. I'll open a separate portable-pty PR upstream (env-var-gated PSEUDOCONSOLE_PASSTHROUGH_MODE opt-in, default off, no behavior change for existing callers).
3. Once that's merged + released, a follow-up Ratty PR can bump portable-pty and either default the flag on for Ratty or expose it via ratty.toml.

Happy to file a tracking issue against Ratty in the meantime so this doesn't get lost.

Pushed fbc8e2d (force-update of b521537) — refactored find_git_bash per a code-taste review: the %LOCALAPPDATA%\Programs per-user install was special-cased after the main env-var loop, which is exactly the kind of structural smell that's a one-row-table-extension waiting to happen. Folded everything into a single const CANDIDATES: &[(&str, &str)] table walked once, PATH fallback after. Same behavior, ~10 fewer lines, easier to extend (Scoop / Chocolatey / custom installers = add a row). cargo fmt --check, cargo check, cargo clippy -D warnings all green.

Heads-up on the RGP follow-up — my earlier comment was wrong.

I pulled a vendored portable-pty 0.8.1 source from crates.io, gated the PSEUDOCONSOLE_PASSTHROUGH_MODE flag behind an env var, [patch.crates-io]'d it into a probe, and verified the env var fires, CreatePseudoConsole is called with flags=0xe (0x6 default | 0x8 passthrough), and bash launches correctly. Same probe writes a known APC out of bash (printf '\x1b_PROBE;hello=world\x1b\').

Result: ConPTY still strips APC sequences even with PSEUDOCONSOLE_PASSTHROUGH_MODE enabled on Windows 11 26200.6457.

=== WITH PASSTHROUGH (flags=0xe) ===
PTY master receives 100 bytes:
  ConPTY init + BEGIN-MARK + OSC 0 (title) + END-MARK
  (no \x1b_, no PROBE;)

Bash's own xxd of the exact bytes it printed:
  BEGIN-MARK 1b 5f P R O B E ; h e l l o = w o r l d 1b 5c END-MARK

So bash emits the APC correctly, and ConPTY drops it regardless of the passthrough flag. The #[allow(dead_code)] on the flag in portable-pty is starting to look intentional — the upstream maintainer may already know this. The earlier "submit an upstream PR exposing the flag" plan is moot; the flag doesn't actually solve it.

I'm going to take this back to the drawing board (OSC-wrapped RGP / side-loaded openconsole conpty.dll / how Microsoft Terminal handles inline graphics) and update #67 with the empirical evidence. The shell-default work in this PR is fully independent and ready for your call.

Side-load test: latest microsoft/terminal ConPTY also doesn't pass APC through.

Pulled Microsoft.Windows.Console.ConPTY.1.24.260512001.nupkg from microsoft/terminal release v1.24.11321.0, extracted conpty.dll + OpenConsole.exe, dropped them next to the probe binary. Confirmed portable-pty::load_conpty() picks up the sideloaded conpty.dll (init bytes change from in-box's \x1b[?9001h\x1b[?1004h to sideloaded's \x1b[1t\x1b[c\x1b[?1004h\x1b[?9001h — different ConPTY version observed at the wire). Process tree confirms OpenConsole.exe is spawned by the sideloaded DLL as expected.

Same APC-emitting bash script, both with and without PORTABLE_PTY_CONPTY_PASSTHROUGH=1 set:

=== sideloaded conpty.dll, flags=0x6 ===
Total bytes read: 23
0000: 1b 5b 31 74 1b 5b 63 1b 5b 3f 31 30 30 34 68 1b 5b 3f 39 30 30 31 68    .[1t.[c.[?1004h.[?9001h

=== sideloaded conpty.dll, flags=0xe ===
Total bytes read: 23      (identical bytes)
Contains \x1b_ (APC start)?  false

Cross-checked against an upstream research dive (Microsoft Terminal PR #17510, issue #17313, Ecosystem Roadmap):

• PSEUDOCONSOLE_PASSTHROUGH_MODE isn't a real public flag. 0x8 in the current winconpty.h is PSEUDOCONSOLE_GLYPH_WIDTH_GRAPHEMES, not passthrough. The #[allow(dead_code)] constant in portable-pty traces back to an old proposal that never shipped.
• The 1.22 "ConPTY passthrough" work was a synchronisation refactor, not a sequence-forwarding feature. It enabled unrecognised sequences to pass through into conhost's own renderer (which is how Sixel got rendered inside Windows Terminal). It does not forward APC to third-party hosts.
• APC is consumed by ConPTY's VT parser unconditionally in every shipping version, including the latest sideloadable NuGet. OSC survives (with caveats — Warp tracks an ordering bug in issue #17313). Recognised DCS survives. Everything else is dropped.

So both ConPTY hypotheses are dead:

1. In-box kernel32.dll ConPTY + flag — flag isn't real.
2. Side-loaded conpty.dll from latest microsoft/terminal — empirically still strips APC.

This makes OSC-wrapped RGP the only viable path on Windows. It's not pretty, but it's the path that works without waiting for Microsoft to add APC to the passthrough roadmap (which it isn't on). I'll update #67 with the full evidence and start sketching what an OSC wrapping might look like that survives ConPTY's ordering quirk.

The shell-default work in this PR remains fully independent of this rabbit-hole.