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/
jianpingzhan's point about attaching proof, and your reply that a screenshot can look right while the interaction is broken, land on the same edge. A live preview closes the gap a screenshot leaves. It leaves a different one open, and I missed it for weeks.
My news pipeline had three layers stopping it from posting the same story twice: a feed filter, a spreadsheet of seen URLs, and an LLM judge as the last line. Weeks after launch I noticed the judge had skipped the same article four separate times in about two weeks. The spreadsheet had never worked. One config value was unset since day one, the code logged a warning nobody reads, and it returned empty. Layers one and three were leaking too, in ways that happened to cancel out. No duplicate ever went live, so nothing in the output looked broken.
That is what nags at me about answering Ericluck666's live-versus-snapshot question with live, at least for web projects. A live preview is still an output check. Tapping around a working page tells you the result is right today. It stays quiet about a guard you are counting on that has not executed since you shipped it. Until the day it matters, a guard that never runs looks exactly like a guard that runs and passes.
Mine did leave a trace, a warning line in a log nobody opens. What was missing was that trace showing up where I was already looking: which checks ran on this change, and which ones returned nothing, per run.
So the call I would put in front of you: decide which of those two the phone shows first, before you tap anything. If the result comes first, you have built a faster way to look at the page, which is worth having, and the phone does not add a detector for a silent guard. If the record of what verified it comes first, then the trips back to the laptop you are trying to remove become the ones where something actually needs a human.
The part about nothing looking broken is what sticks with me. I wouldn’t have caught that by opening the preview either. Porta makes it easier to inspect the work from a phone; it doesn’t by itself prove that a guard ran.
I’d want a short record beside the preview: which checks were expected, which ran, and where there’s no result. Missing evidence shouldn’t look like a pass. The project still needs to define those checks—just pulling more logs onto the phone won’t solve that.
Did you end up making missing config fail the run instead of logging a warning?
No, and I should say so plainly. That guard still logs a warning and returns today. What I did in the moment was set the missing value and backfill the sheet with the URLs it should have recorded. The change that stuck landed on a different guard: the run's completion mail now carries one line per post saying which path produced its image, and the fallback path is flagged. That guard reports itself now. The seen-URL layer still has no per-run line, and I have not audited the other two layers the same way.
On fail versus warn, I would not fail the run. For an unattended pipeline that would have stopped every post, and no duplicate was going out. What I would build is the record you described: a line beside each run reading "seen-URL check: no result", with the absence spelled out. That is what would have caught it in week one.
Got it, thanks for clarifying. I like that the image-path line lives in the completion email, somewhere you already check. I’d separate the two decisions: whether a missing check should block a run depends on what it protects, but its absence should be visible either way. That’s more useful than asking someone to dig through logs when the output looks fine.
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.
Exactly — tying the proof to the exact version is what makes it trustworthy rather than decorative. A commit hash or run id next to the before/after closes the 'which code does this belong to' loop, and it doubles as a review trail when you come back to the task later from the phone. Sounds like you already know the shape of it.
Yes, especially when I come back after the agent has made a few more changes. “This passed” isn’t much help if it belongs to an older run. I’d want that mismatch to be obvious, rather than having to reconstruct it from the terminal history. Thanks for spelling that out.
Exactly — the mismatch being obvious is the feature, not a nicety. Good luck with Porta, and I'll be curious to hear how the evidence-attachment loop lands once you ship it.
Thanks! If you use CLI agents and tmux, would you be up for trying the current Porta workflow with one real task from your phone? I’d appreciate knowing where managing the task or checking its live preview still makes you reach for the laptop. The app is here: https://porta.fatclaw.com/ — happy to help with setup.
Happy to — I work with a CLI coding agent (opencode) from a Mac, so the workflow maps well. My machine is SSH-reachable from my own network; send me the setup steps and I'll try it with a real task this week. Honest caveat: I'm usually at my desk anyway, so the 'check from the phone' scenario will be half-simulated — but the live-preview + annotated-feedback loop is exactly what I want to feel out.
Exactly — the mismatch being obvious is the feature, not a nicety. Good luck with Porta, and I'll be curious to hear how the evidence-attachment loop lands once you ship it.
"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.