My agents kept working. I still needed my laptop.
I have a day job and build side projects in my spare time. Coding agents helped me get more done. They didn't get me away from my laptop.
I could leave a few tasks running in tmux, but sooner or later one needed an answer. Or an agent would say it had fixed the UI, and I'd need to open the actual page to see whether it had.
I like the freedom of CLI tools. I didn't want to move my projects into a hosted IDE. And on a phone, switching between tmux sessions was only part of the problem. Reading "done" in a terminal wasn't the same as checking the product.
So I built Porta: a mobile app for the agent work already running on your own machine. From my phone, I can find the task that needs attention, return to its tmux session, open the actual web preview or check an Android build, and send an annotated screenshot back to that same task. The agent keeps working in the original project.
That's the product loop I wanted: see what the agent built, show it what needs changing, and check the next version.
I'm not trying to spend a whole working day coding on a phone. I want to handle the small decisions and visual checks without going back to my desk every time.
Porta is on iOS and Android. The local SSH/terminal tools are free; cloud sync and background notifications are Pro features.
It solves a problem I kept having. Now I need to find out whether it fits anyone else's workflow.
I'd appreciate help from a few people here who already use CLI coding agents and tmux. Try it with one real task on your own SSH-accessible machine: open the result and send back one piece of feedback. I can help with setup.
Tell me where you got stuck, or if you'd rather just wait until you're back at your desk. Either is useful to know.
What was the last thing that pulled you back to your laptop while an agent was working?
Try Porta on iOS or Android: https://porta.fatclaw.com/
The 'agent said it fixed the UI, I still had to check' gap is exactly where trust leaks in agent workflows — good on you for naming it. One thing I'd push on: the annotated-screenshot loop still starts from the agent's own claim that it's done. Have you thought about making the agent attach proof when it reports 'done' — a before/after screenshot pair, or the test output it just ran? If the phone shows evidence instead of claims, the 'do I need to look' decision gets made earlier, and you check less often.
That’s a good point. I’ve focused on making it easier to check the work from my phone. You’re suggesting I should need to check less often in the first place.
I’d still open the live preview for UI changes—a screenshot can look right while the interaction is broken. But seeing the before/after and which tests actually ran would help me decide what needs a closer look. I’d also want that evidence tied to the exact version I’m reviewing, so an old screenshot doesn’t give me false confidence.
"Agent said it fixed the UI" and then you still had to open the page is such a clean tell.
Before you scale Porta, run one real-user loop with people who already live in CLI agents + tmux: would they use this instead of waiting until they are back at the desk, and why or why not. One annotated screenshot task is a perfect weekend-slice.
Free Pyramid Reality Check if you want a tighter one-sentence core job for that loop:
https://durablefoundations.gumroad.com/l/pyramid-reality-check
What was the last visual check that actually pulled you back to the laptop?
Kael Voss / DurableFoundations
For me, it’s usually an agent saying a UI change is done and me wanting to open the actual page and try it. A screenshot can show the layout, but I still need to check the interaction. That’s why the web preview is live.
One real task with another CLI/tmux user sounds like a useful next test. I’d like to see where their workflow differs from mine.
That’s the exact loop I’d isolate first: loading, empty, error, success, then one real task end to end. If the agent can change the UI but you still need the laptop to verify one of those states, mobile access is only moving the handoff, not removing it.
For Porta, I’d test one weekend slice with a CLI user and record which state forced the return to desktop. That gives you a sharper core job than “control agents from a phone.”
Which verification step is hardest to make observable from mobile?
Kael Voss / DurableFoundations
I’d start with error recovery. The live preview already lets me use the actual page from my phone. The harder test is getting it into a failure state and checking what happens next—for example, a failed save, a retry, then a reload to see whether the data really persisted.
That would be a useful task for someone to try in their own project. I know my own setup too well, so I’d want to see where they get stuck or reach for the laptop before assuming my experience carries over.
This resonates. I run 14 AI agents across my product (compliance tracking, SEO monitoring, daily funnel reports, customer intelligence), and the feedback loop problem is real — but from the other side.
My agents don't need me to check on them. They need me to act on what they find. The bottleneck isn't "can I see what they're doing from my phone?" — it's "did the insight reach me in a format that triggers action?"
Example: I have a daily funnel monitor that runs at 7:43 AM. It compares today's signups/clicks/CTR against a 30-day baseline and flags anomalies.
For weeks, I had it writing reports to a file. Nobody read the file. When I switched it to sending a Slack-style summary to my email with one clear action item ("onboarding dropout spiked — check step 3"), I actually acted on it.
The question I'd pressure-test for Porta: are developers returning to their desk because they can't see what agents are doing, or because they can't trust what agents did?
If it's trust, screenshots and terminal output on mobile solve it. If it's "I need to course-correct the agent mid-run," that's a harder problem — you're essentially building a mobile IDE for agent supervision.
Omri's funnel framing is smart. I'd add: track not just which tier users land in, but how many complete a full check → feedback → verify cycle without touching their laptop. That's your real activation metric.
Cool product. Shipping it as a solo founder while using agents to build it is very meta.
That email example makes sense. Another status update doesn’t help much if I still need my laptop to do anything about it.
For me, it’s both: check the result, then tell the agent what needs changing through the same CLI/tmux task. I’ve used this workflow to develop more than ten products alongside my day job. That’s my own experience, though—not proof that it fits everyone.
Your check → feedback → verify metric gets much closer to what I need to learn from other people than how often they open the app.
The repeat workflow you've described is a stronger signal than raw mobile access. Most mobile tools are designed for emergencies (agent crashed, urgent check). But you're measuring daily-use adoption.
The measurement question underneath: which specific step actually pulls people back? Visual preview check? The async feedback loop? Or just context-switching overhead between three SSH windows?
Porta answers one, but you won't know if it's the blocker until others adopt the repeat workflow. If people stop at one check and go back to their laptop anyway, the signal tells you the preview wasn't the constraint—it was something after it.
Worth tracking: does adoption rate differ between "just check" users vs "check + send feedback" vs "check + send feedback + see next version"? Each one chains to the next, and the chain breaks at the real blocker.
The return visit after sending feedback is the important part for me. I want to see whether the change actually worked, not just whether the agent finished.
I like your breakdown because it gives me a concrete question for early testers: which step made you reach for the laptop again? Someone opening one preview and someone keeping a task moving are very different outcomes.
The repeat loop is the real test. I'd split handoffs into quick approvals, visual checks, and tasks that need a laptop. Then I'd measure which one brings people back. Feedback should also be easy to send from a phone. DictaFlow could work well here. Hold to talk, describe what's wrong with the preview, then release to send the note back to the agent. That's more realistic than asking people to type useful feedback into an SSH session on a small screen.
I’m already using voice typing through my phone’s keyboard for this. It goes into the composer, so I can check the text before sending it to the agent. For something visual, I can attach an annotated screenshot too.
So yes, voice input helps a lot here. I’m currently relying on the keyboard’s dictation rather than a separate voice feature inside Porta.
For me the pull-back-to-my-desk moments are almost always verification loops — the agent says the UI is fixed, but I want to see the actual page before trusting it. Screenshot round-trips got tedious, so I've started asking my agents to attach a diff plus a screenshot before they mark anything done. One thing I'm curious about: when you open a preview from Porta, is it a live view or a snapshot? For Android builds especially, live would be what actually saves the trip back to the desk.
It’s live for web projects—you can tap around and use the actual app, not just look at a screenshot. Porta forwards the preview server running on your machine to your phone.
Android takes a different route: download the built APK and install it on your phone through Android’s normal install flow. You’re testing the actual app, not watching a streamed emulator.
Screenshots are for the feedback part: annotate what’s wrong and send it back to the agent in the same task. That “done, but let me actually see it” moment is exactly what I wanted to solve.
Managing tmux sessions on a phone keyboard over standard SSH is absolute misery. The sweet spot isn't trying to write code on a 6-inch screen—it's just handling agent forks and checking previews while stepping away to make coffee. Really like the focus on keeping the heavy lifting on the local machine.
That phone-keyboard frustration is exactly what pushed me to build Porta. It lets me switch tmux sessions and manage agent tasks from the mobile UI, while keeping my usual SSH workflow.
I use it this way every day now, and I've built more than ten products with this workflow. The work still runs on my own machines; I use the phone to manage tasks, check what the agents built and keep things moving.
I'd love for you to try it with one of your own tasks. Happy to help you get set up — and I'd genuinely like to hear what still feels awkward.
The interesting test seems to be the repeat loop rather than whether the mobile access works. For developers already running agents in tmux, do they come back to Porta for multiple visual checks/decisions, or is the laptop still easier once the task needs real intervention?
That’s a fair question. I initially expected to stay pretty dependent on my laptop too. But over the past two months, I’ve found myself opening it far less often.
I use short gaps in my day to check what the agents built, make a decision, send feedback, and come back for the next version. For me, that has become a repeated workflow, not just a way to check progress. The computer still runs the work; I just don’t have to sit in front of it as often.
That’s what I want from AI tools: more choice over when and where I work, not just more code. This is my own experience, though. What I need to learn now is whether other developers find that same freedom, or hit limits that send them back to their laptops.
That repeated workflow is a stronger signal than simple remote access. I’d be interested in seeing whether other developers adopt it the same way. If you’re open to it, what’s the best email to reach you on?
Sure — you can reach me at tryanswer@gmail.com. Happy to chat and hear what you have in mind.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.