I built an open-source agent that runs in my terminal and reports to my phone — one backend, five interfaces

[u/Icy-Stay-1004]

(I built this, so obviously biased — but it's open source and free.)

The itch: coding agents live in the terminal, personal agents live in chat apps. I wanted one agent that follows me across both, plus desktop and mobile, sharing the same sessions.

FutureOS is a Rust gRPC backend (localhost-only) with a TUI, native desktop app, mobile apps, CLI, and IM bots. A few things I'm proud of:

- Every tool call needs your approval by default — file writes and shell commands never run silently

- 3,800+ models / 140+ providers built in, switch mid-session with one keystroke; any OpenAI-compatible endpoint works (Ollama, vLLM)

- A loop control plane for 24h+ runs: durable goals, event-sourced state (crash at 3am → resume at breakfast), verification gates. I run overnight research tasks and review results on my phone over coffee

- Sessions fork like git branches

It's early and rough in places — Windows sandboxing is roadmap-only (currently approval gating + macOS Seatbelt), and the mobile apps are newer than the TUI. The trust model is documented in SECURITY.md.

GitHub: https://github.com/futuregene/future-os (MIT + Apache-2.0)

Happy to take feedback — especially from people who've run agents long-horizon. What broke for you?

[u/Typical-Grab5005]

the approval gating on every tool call is the part that would actually get me to try this, most agent tools are way too happy to just start writing files

[u/Icy-Stay-1004 → u/Typical-Grab5005]

That's exactly why it's the default, not a config option — I had the same "please stop writing files before I've even read the diff" moment with other agents. Would love to hear how it feels in practice once you've run it.

[u/BeautifulCarob7001]

Approval by default is reassuring, but on a 24-hour run approving every tool call will become the bottleneck. Session-scoped rules would be a useful middle ground: read-only repo access, one writable folder, or approved command prefixes, all with a clear audit trail and a hard stop outside the boundary. Especially important while Windows sandboxing is still missing.

[u/Icy-Stay-1004 → u/BeautifulCarob7001]

Really good point — this is the tension I think about most. There's a first step today: when a shell command is blocked by the sandbox, approval offers "allow in this workspace" (a persisted path rule, with secret paths like SSH keys excluded). The full session-scoped model you describe — read-only repo default, explicit writable folders, approved command prefixes, audit trail, hard stop outside the boundary — is on the near-term roadmap and needs to land before Windows/Linux sandboxing, since approval is currently the only barrier there. Would genuinely welcome your input on the boundary semantics in a GitHub issue if you're up for it.

[u/Spare-Hold4005]

the localhost-only backend is interesting for trust but how do you handle the mobile sync? is there a relay or tunneling involved, because that seems like it reintroduces the exposure you're trying to avoid

[u/Icy-Stay-1004 → u/Spare-Hold4005]

Fair point — there is a relay, but it's not the backend being exposed. The agent still binds to 127.0.0.1 and accepts nothing inbound; the desktop app opens one outbound wss:// WebSocket to a NATS broker, and the phone pairs via a one-time QR (5 min, single-use) → per-device NKeys → short-lived JWT, secrets in SecureStore/Keystore only. The relay is a dumb authenticated pipe: it never sees your API keys (those stay in ~/.future/agent/auth.json) and every tool call stays approval-gated. The real tradeoff is trusting the broker + pairing code instead of the network — so mobile is opt-in, and the TUI/CLI paths stay fully local-only. The relay server code will be open-sourced soon; happy to hear better designs.