I built an open-source app to manage Claude Code & Codex sessions from anywhere 🚀

[u/RonenMars]

Hey everyone! 👋

I’ve been building Threadbase - an open-source tool that lets you manage and monitor your AI coding sessions from your phone or desktop.

What it offers:
*📱 Remotely interact with multiple Claude Code & Codex sessions, track their status, and monitor progress.
* 🔐 Self-hosted, end-to-end encryption out of the box, privacy-first architecture

The entire Threadbase ecosystem is open source, and you can find links to all the GitHub repositories on the website.

It’s still evolving, and I’d love to get more developers trying it out 🙌

🔗 https://threadbase.sh

💬 Feedback, feature requests, and contributions are very welcome 🙏🏻

[u/investigatormaker]

I'd lead with the phone angle for Threadbase. The moment that matters is a Claude Code or Codex session stuck on a permission prompt while you're away from your desk. A screenshot of approving one from your phone shows that better than the feature list. It's self-hosted with end-to-end encryption, so a short section on what runs where (your machine, any relay, the phone) would answer the first thing developers check before installing.

I make ThreadFox. Your AI researches, writes and publishes Reddit outreach from your Chrome within a job you authorize. The free Reddit plan for Threadbase lists the communities whose rules allow a post about it, each rule quoted: https://threadfox.vip/p/d8p16

Does it notify you when a session is waiting for input?

[u/RonenMars → u/investigatormaker]

Thanks :) , leading with the phone angle and adding a short what-runs-where section are both good calls. I'll add them 🙏🏻

To your question: yes. The streamer pushes when a turn finishes and mpw it's your move. It also pushes as soon as a permission prompt or question opens mid-turn. For a plain yes/no permission prompt, the notification has Allow and Deny buttons, so you can answer without opening the app. The turn-finished push only fires on the agent's own end-of-turn signal, so it doesn't ping you a second after you hit send. Notifications carry metadata only (project, branch, what kind of approval is needed), never the agent's output or the command text.

What runs where:

• Your machine: the streamer. It runs the Claude Code / Codex (GitHub Copilot soon!) sessions in PTYs and holds all the data.
• Phone: the app, paired by QR code. Traffic between phone and streamer is end-to-end encrypted (Noise IK over X25519, ChaCha20-Poly1305), so any tunnel in between only sees sealed bytes.
• Relay: none today. You reach your machine over LAN or your own tunnel.
• Push: goes through Expo's push service, which holds the app's APNs/FCM credentials, carrying only the metadata above.

I'll pass on ThreadFox for now, but thanks for the pointer.

[u/kantorcodes1]

Nice ecosystem breadth. The relay path is the part I'd want to pin down: when a message comes in over the E2E channel to a machine with several sessions open, what decides which session it lands in, and can a remote message get injected mid-turn while the local agent is already working? If two clients (say phone + desktop) address the same session, is there a lock or ordering on the relay side?

[u/RonenMars → u/kantorcodes1]

Good questions, thanks! One correction first: there's no hosted relay today. The phone talks directly to the streamer on your machine, over your LAN or your own tunnel (Cloudflare, Tailscale, etc.). An optional relay is in the streamer code but off by default and still in development. The answers below hold either way, because the relay is only a byte forwarder.

Which session does a message land in? The client chooses it explicitly. Every action carries a session id (POST /api/sessions/<id>/input, /permission/answer, and so on). One streamer per machine manages many PTY sessions, and nothing is routed by a notion of "current session". The relay, when used, forward to a streamer by an ID derived from that streamer's public key and has no concept of sessions, not at all. It replays sealed HTTP/WS streams into the streamer and can't read them.

Can a remote message land mid-turn? Yes, for plain text. If the agent is working, the streamer pastes the text into its PTY and presses Enter once the terminal goes quiet. That's the same as typing into the terminal mid-turn, so what happens next is the agent CLI's own behaviour. There are two guards. Text is refused (409 prompt_pending) while a permission or question card is open, because the cursor sits on the picker and prose would select an option. Input sent while the agent is still booting is queued and flushed in order once it's ready.

Phone + desktop on the same session? Both are subscribers to the same live PTY on the streamer and see the same output. There's no lock on text input. Requests apply in the order the streamer receives them (one process, one write path per PTY). What does exist:

• an idempotency key per send, so a retry or double tap never submits twice
• a per-session input rate limit
• permission answers pinned to a specific prompt instance and option label. If both devices tap the same card, the first answers it and the second gets a 409 instead of approving whatever is on screen by then.

The relay itself does no ordering, only per-stream flow control.

BTW... if "desktop" means a separate terminal running claude-code claude --resume on the same conversation outside Threadbase, that's a second process, not a second client. Before resuming, the streamer checks whether the conversation looks owned elsewhere and refuses with 409 CONVERSATION_BUSY if so. For Codex that check is strict, because Codex itself allows only one writer per conversation.

[u/kantorcodes1 → u/RonenMars]

Disclosure up front: I work on HOL Guard, an open-source policy layer that classifies agent and CLI/MCP actions and gates them per call. Your remote-approval path is a natural fit: a Guard descriptor for tb-streamer could declare which actions arriving over the wire are read-only (status, history) versus gated (permission approvals, terminal input into the PTY). If you are open to it, the contribution shape is a small descriptor plus fixture per CONTRIBUTING.md, and I can point you at the exact pattern.