we've run into this problem. when you're running 4-5 Codex/Claude Code sessions in parallel across worktrees, the port collision sucks. have to check out
We’ve been building in this space for a while, and the issues listed here are exactly the hard parts: session connectivity, reconnection logic, multi-session UX, and keeping state in-sync across devices. Especially when it comes to long running tasks and the edge cases that show up in real use.
Good question. We don't have E2EE yet (it's on the roadmap), so some level of trust in Omnara is required today. All repo operations happen locally on your machine. For messages/chat history: we store those encrypted at rest because we need access to sync across devices, send notifications, and resume agents. Cloud sandboxing is opt-in and would require syncing codebase state.
Totally get it, we're trying to minimize subscriptions too. Free tier gives you 10 sessions/month with no length limits, so you can actually get a decent amount done before deciding if it's worth paying
Thanks for the shout! Happy looks solid - always great to see more options here. Anecdotally from users who've tried both, we've heard Omnara has better reliability and latency. We also layer on some features like web support, worktrees, sandboxing, richer git management (diffs, checkpoints), and preview URLs. Would love to hear what you think if you give it a spin :)
Fair concern. We don't have true E2EE yet because our service needs access to message content for cross-device sync, notifications, and agent execution. Everything is encrypted in transit and at rest, and all repo operations happen locally on your machine.
We've heard this from other users and it's on our roadmap. The challenge is we're building features like voice coding agents and hosted sandboxes that require plaintext inputs, so we'd need two execution models. Doable, but adds complexity for our team size.
That said, it's something we're prioritizing as we grow. No promises on timing, but it's coming.
thats a great stab :) We dig into this in the post, but the key distinction we landed on is that the trigger can be asynchronous without the agent itself being async. A cron job, webhook, or autonomous trigger is really about scheduling, not a property of the agent’s execution model.
In other words: triggering without a human ≠ async by itself. What matters is whether the caller blocks on the agent’s work, as opposed to how or when it was kicked off.
hey, ishaan here (kartik's cofounder). this post came out of a lot of back-and-forth between us trying to pin down what people actually mean when they say "async agents."
the analogy that clicked for me was a turn-based telephone call—only one person can talk at a time. you ask, it answers, you wait. even if the task runs for an hour, you're waiting for your turn.
we kept circling until we started drawing parallels to what async actually means in programming. using that as the reference point made everything clearer: it's not about how long something runs or where it runs. it's about whether the caller blocks on it.
Nice setup, clever way to keep it moving without much manual intervention. Curious, do you review the logs in between, or is it more of a yolo “continue” each time?