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
| Test | Purpose |
|---|---|
| Rust unit test | Validate model IDs, ports, paths, and args |
| Frontend mock test | UI handles readiness, stderr, failure, and stopped states |
| Integration smoke | Sidecar starts, reports ready, serves one request, and stops |
| Release smoke | Packaged artifact includes correct sidecar binary |
| Cleanup smoke | App exit kills or gracefully stops child processes |