Sidecar-Backed AI Tool

This walkthrough traces a Tauri app that supervises a local AI sidecar.

Flow

User enables local model
  -> UI calls `startModelServer()`
  -> Rust validates requested model id
  -> Rust resolves bundled sidecar path
  -> Rust starts sidecar with fixed args and per-install token
  -> Rust streams readiness/log events to UI
  -> UI calls local API through Rust or a constrained localhost path
  -> App exit triggers sidecar cleanup

Why Rust Should Own The Sidecar

The renderer is not the right place to decide executable paths, free-form args, ports, or cleanup behavior. Let Rust own process supervision and expose small commands such as start_model, stop_model, and model_status.

Sidecar Config Review

bundle.externalBin lists every sidecar name
binary exists for each target triple
shell permissions are narrow or not exposed to frontend
args are fixed or validated
stdout/stderr handling is tested
ports are loopback-only by default
tokens are generated per install or per session
cleanup runs on app exit

Security Review

Ask these before shipping:

Can user text become a shell argument?
Can remote content reach the sidecar port?
Can another local process call the sidecar API?
Are prompts, file paths, or tokens logged?
Can the sidecar read outside approved directories?
How is the sidecar updated and signed?

Tests

TestPurpose
Rust unit testValidate model IDs, ports, paths, and args
Frontend mock testUI handles readiness, stderr, failure, and stopped states
Integration smokeSidecar starts, reports ready, serves one request, and stops
Release smokePackaged artifact includes correct sidecar binary
Cleanup smokeApp exit kills or gracefully stops child processes