Follow-up: unify external tool dependency detection

[jamesbrink]

Follow-up from #786 (feat/native-codex-harness) and #808 (feat: promote agent backends to first-class settings).

Current status

PR #808 is merged, so the baseline has changed:

• Native Codex is now a first-class Settings > Models backend using codex app-server --listen stdio://.
• Alternative Claude Code backends and Codex are no longer configured from Experimental.
• Claude Code and Codex auth recovery now live together in Settings > Models.
• Codex model refresh can run in the background at startup.
• Direct Codex CLI probes in the Tauri backend now use a centralized command helper that applies the Windows no-console guard.
• A small audit also applied the no-console guard to other quiet Windows helper spawns found during feat: promote agent backends to first-class settings #808: AppX icon extraction, copy-image PowerShell, and WebView2 download URL launch.

The missing-dependency story is still split across multiple tool-specific paths, though, and #808 makes the need for a shared dependency/capability layer more obvious.

Existing pieces

Claudette already has a missing-dependency flow for tools such as Claude CLI, Codex CLI, Git, and GitHub CLI:

• src/agent/binary.rs resolves claude / codex via process PATH, login-shell PATH, platform-specific binary variants, and well-known fallback locations.
• src/git.rs has a parallel resolve_git_path_blocking resolver with Git-specific fallback locations.
• src/missing_cli.rs maps spawn NotFound into MISSING_CLI:<tool> and provides per-platform install guidance for claude, git, and gh.
• src-tauri/src/missing_cli.rs turns those sentinels into the missing-dependency event, and the frontend caches/renders the MissingCliModal plus chat inline install affordance.
• src-tauri/src/commands/agent_backends.rs now has Codex-specific command helpers and auth/model-discovery probes for the first-class Codex backend.

Problem

The app-detection surface is still split across tool-specific resolvers, spawn sites, and the shared missing-CLI sentinel/guidance layer. That works today, but platform behavior can drift:

• claude and codex share most resolver needs but still rely on tool-specific call sites.
• git has a similar resolver shape but lives separately.
• gh has install guidance, but detection depends on plugin/runtime spawn sites rather than an explicit shared resolver.
• Settings can show Claude/Codex auth state, but the app still lacks a central dependency inventory that can say whether the required external tool itself is installed before a failed spawn.
• Platform-specific binary variants, install locations, GUI PATH enrichment, and Windows no-console behavior are encoded in multiple places.
• Background probes, especially on Windows, need a reliable way to opt into quiet/no-console spawning without each call site remembering the platform details.

Proposed follow-up

Design and implement a unified external-tool dependency / app-detection layer for required external tools.

Suggested direction:

• Add a small registry of known external tools (claude, codex, git, gh, maybe future env-provider CLIs) with:
  • display name and purpose
  • platform-specific binary names / executable suffixes
  • PATH lookup behavior
  • login-shell or enriched PATH behavior where applicable
  • well-known install locations
  • install guidance
  • whether the tool is required globally or only for a feature/backend
  • whether the tool should be spawned visibly or quietly in background probes
• Reuse the registry from resolver code and from guidance_for(...) so detection and UX cannot drift.
• Provide command-construction helpers for common spawn modes:
  • interactive/user-visible launches
  • quiet background probes that must not show Windows console windows
  • current-dir checked commands that must preserve MISSING_CWD:<path> behavior
• Preserve the current safety properties:
  • skip non-absolute PATH entries
  • do not cache bare-name fallbacks
  • preserve MISSING_CLI:<tool> and MISSING_CWD:<path> behavior
  • keep precheck_cwd(...) before any spawn with current_dir(...)
  • preserve Windows CREATE_NO_WINDOW behavior for quiet background probes
• Add a Tauri/query surface for dependency status so Settings/onboarding/diagnostics can show missing tools before the first failed chat/repo/plugin action.
• Keep dependency availability separate from auth/account state:
  • claude installed vs Claude Code signed in
  • codex installed vs codex login valid
  • git installed vs repo path valid
  • gh installed vs authenticated to GitHub
• Make sure Windows shims/native executables remain covered (.exe, .cmd, .ps1, npm shim behavior, official installers), and macOS/Linux GUI launches continue to use enriched/login-shell PATH behavior where appropriate.

Acceptance criteria

• claude, codex, git, and gh detection are described by one shared registry or equivalent abstraction.
• Existing missing-dependency modal behavior continues to work for spawn failures.
• Settings, onboarding, or a diagnostic command can preflight dependency status without requiring a failed chat/repo/plugin action first.
• Claude/Codex auth status remains surfaced in Settings > Models, but depends on the shared tool-availability layer for the installed/missing CLI state.
• Background dependency probes and model/auth refresh commands do not create visible Windows console windows.
• Platform-specific tests cover at least:
  • process PATH wins
  • login/enriched PATH lookup where applicable
  • well-known fallback path lookup
  • bare fallback is not cached
  • Windows executable/shim variants
  • quiet Windows probes use the no-console spawn path
  • MISSING_CWD is not misreported as missing CLI

References

• PR: feat: add native codex harness foundation #786
• PR: feat: promote agent backends to first-class settings #808
• src/agent/binary.rs
• src/git.rs
• src/missing_cli.rs
• src-tauri/src/missing_cli.rs
• src-tauri/src/commands/agent_backends.rs
• src/ui/src/components/modals/MissingCliModal.tsx
• src/ui/src/components/settings/sections/ModelSettings.tsx