[Feature] Add Nushell as a first-class supported shell — 500MB+ RAM and ~1s cold-start savings for the headline 5-worktree use case

@OrcaWin is already working on this.

Since Jul 20, 2026.

## Summary

Orca's terminal layer currently treats the user-shell as roughly equivalent
across Windows shells, but the per-process footprint difference between
PowerShell and Nushell becomes a real cost in Orca's own headline workflow
— fanning one prompt across multiple parallel worktrees.

I measured the gap on a clean Windows 11 dev box, idle shell session,
default config, no other workload:

| Shell | RSS (idle) | Cold start | 5 parallel worktrees (RSS) | 5 parallel cold starts |
|--------------|------------|------------|----------------------------|------------------------|
| PowerShell 7 | ~150 MB | ~300 ms | **~750 MB** | **~1.5 s** |
| Nushell | ~45 MB | ~100 ms | **~225 MB** | **~500 ms** |

For the 5-worktree scenario that Orca's README literally puts on the
cover ("fan one prompt across five agents, each in its own worktree"),
that's a **~525 MB RAM delta and ~1 s of cumulative cold-start latency
savings** — not from changing Orca's architecture, just from letting the
user pick a lighter-weight shell for the outer session.

## Why this fits Orca's design

**1. The resource math compounds at Orca's headline use case.**
Orca's README sells "fan one prompt across five agents, each in its own
worktree" as the differentiator. Per-worktree shell overhead scales
linearly with that count. Picking a lighter-weight outer shell is a
free ~500 MB and ~1 s of cold-start latency in that scenario — with
zero change to agent behavior.

**2. Cross-platform shell matches Orca's cross-platform product.**
Orca ships on Windows, macOS, and Linux. Today the shell story is
asymmetric: Windows has a Settings picker (PowerShell / CMD / WSL);
macOS and Linux silently use the system shell. A developer who moves
between a Windows laptop and a macOS box — and through Orca's SSH
worktree into a remote Linux host — gets the same shell syntax, the
same config, the same aliases, and the same prompt everywhere
Nushell is installed. That is the same "write once, run anywhere"
pitch that drove PowerShell to go cross-platform; Nushell just took
it further by being POSIX-inspired and Rust-native instead of .NET-
bound. Concretely: my `config.nu` on Windows would just work in
Orca's terminal on macOS and in an SSH worktree on Linux, with no
porting.

**3. Microsoft already treats Nushell as a first-class Windows citizen.**
Nushell is available through the official `winget install Nushell.Nushell`
package, the Microsoft Store, Scoop, and Chocolatey. Microsoft's own
Dev Home demos use Nushell for structured shell workflows. So the
question is no longer "should we support an obscure shell" — Microsoft
has already answered it. Orca just needs to honor that.

**4. Stack alignment with the "100x builders" toolchain.** The Orca
audience already uses the modern Rust CLI toolchain (ripgrep, fd, eza,
bat, zoxide, atuin, starship) and modern terminals (Ghostty, WezTerm,
kitty). Nushell is the shell that wires these together with first-class
integrations — `nu_scripts` is literally organized around this stack.
Supporting Nushell meets Orca's target users where they already live.

**5. Does not interfere with the agent's command execution.**
Agents like Claude Code, Codex, etc. spawn their own POSIX subprocesses;
the outer shell is the substrate the user sees, not what the agent uses
internally. So this is purely an outer-shell UX/resource decision, not
an agent-compat change. Existing agents keep working unchanged.

**6. The "+ new tab" menu is the natural home for data-science workflows.**
Orca's tab bar already exposes a `+` dropdown that lets users open a
one-off tab in any shell without changing their default (PowerShell,
Command Prompt, WSL today). Adding Nushell to that same menu is a
trivial UI change, but it unlocks a use case Orca currently can't
serve: opening a Nushell-with-`polars` tab inside a worktree to do
in-shell DataFrame work on the project's own data files, without
leaving the worktree or spawning an external terminal.

Concrete scenario: a user working in an ML-oriented repo wants to
profile a 4 GB `events.parquet` while their Claude Code agent is
refactoring the training script in the same worktree. Today they have
to leave Orca. With Nushell in the `+` menu, one click gives them:

```nu
ls *.parquet
| polars into-df
| group-by user_id
| agg [sum revenue, mean latency]
| sort-by revenue
| first 20
```

— the only mainstream shell where that pipeline is first-class. The
shell is additive, not a default replacement, so it does not affect
any existing user.

## Concrete symptom this would also fix

This is not theoretical. There's already a filed bug for one slice of
this surface — the SSH relay Node.js detection fails when the remote
login shell is Nushell, because Orca's probe uses `command -v`, which
Nushell does not implement:

→ #7715 — Support Nushell as a remote login shell for SSH relay
Node.js detection

The same POSIX-assumption lives in several other code paths (WSL hook
installer, Quick Commands shell snapshotting, agent status detection),
so each will become the next user-reported issue. A single shell-kind
abstraction closes all of them.

## Proposed scope

A small, focused PR could cover:

1. Add `ShellKind.Nushell` to whatever shell-detection enum Orca already
has (the one extended for fish/zsh in #6037).
2. Dispatch the `command -v` / `which` / env probes by `ShellKind`:
- POSIX: `command -v `
- Nushell: `which | length` (or `^which | path exists`)
- fish: `command -sq `
3. Add Nushell to Orca's `+` new-tab menu (next to the existing
PowerShell / Command Prompt / WSL entries on Windows, and the
existing system-shell entries on macOS/Linux), AND to
**Settings → Terminal → Default shell** for users who want it
everywhere. The `+` dropdown already supports arbitrary shell
commands, so this is mostly a UI listing — but the discoverability
matters: most users will never type a custom command path, they'll
just pick what the menu shows.
4. Honor the user's Nushell login shell in the WSL launch path (currently
unconditionally drops into a POSIX bash).
5. Doc updates in `docs/terminal.md` and `docs/ssh.md`.

## Willing to help

I can test on:
- Windows 11 (Nushell via `winget install Nushell.Nushell`) — reproduces
the 5-worktree RSS numbers above
- macOS 14 (Nushell via Homebrew)
- NixOS remote with Nushell as login shell — reproduces #7715

Happy to open a PR scoped to (1)+(2) first (the shell-detection refactor),
then layer the UI surface on top. Suggested label: `enhancement`, P1
(given the resource impact compounds at Orca's headline use case) or P2
if maintainers prefer to scope it down.

---

cc @stablyai/orca-maintainers — would value a quick read on whether to
keep this as one issue or split "shell-detection refactor" (closes
#7715) from "Nushell UI surface". My preference is one issue so the
broader motivation is visible, but I'll follow whatever's easier to land.