My agents already worked remotely on Linux. I added a macOS node for iOS builds, simulator tests, and computer use.
I asked Codex to test a change in my app on the web and in the iOS simulator, then send me a video. I watched it work through Screen Sharing from my MacBook Air. When I closed the window, the task kept running on the MacBook Pro at home.
Later, I received a recording of the agent using both versions of the app.
The remote Mac is a used MacBook Pro M4 Pro with 48 GB of unified memory. It sits closed in a vertical stand beside my Linux tower. My agents now have a macOS desktop and an iOS simulator on a machine that stays at home, while my Air remains the laptop I carry.
My Linux box had already changed how I worked
In my previous article, I wrote about turning an old gaming PC into an Ubuntu development machine. The repositories, development services, and coding agents ran there. My MacBook Air became the client I used to work with them.
That arrangement started as a way to use the hardware I already owned more comfortably. After using it, I realized I wanted to keep working this way.
I could give an agent a task, close my laptop, and know the environment was still running at home. I could return from my phone without needing the Air to be awake. At a restaurant, I requested a change from Android and checked the result on the same phone while my laptop was off in my backpack.
The part I enjoyed most was being able to leave work running. A longer task didn't require me to keep the laptop in front of me available for the agent.
But some of my development still happened on the Air.
I use React Native for mobile work, and my iOS builds and simulator sessions needed macOS. An agent could work on the repository remotely, but I still brought that work back to the Air to compile and inspect it in the simulator.
Then I started using Codex computer use more often. Here, computer use means letting the agent interact with a graphical interface, such as a browser or an iOS simulator. I liked the macOS implementation. I could ask it to navigate a site or try a flow directly in the app.
Those tasks also used the Air's desktop and its 16 GB of memory. It worked, but I was again giving the agent resources on the machine I wanted to use as my client.
I wanted a Mac at home that could own that part of the work too.
I looked for a Mac mini and bought a used MacBook Pro
A Mac mini seemed like the obvious choice. I wanted a machine I could leave connected at home and reach remotely.
Memory mattered to me. I wanted room for containers, iOS builds, simulators, and computer use. I also wanted to experiment with local inference, even though I hadn't decided what role a local model would have in my workflow.
Finding the right machine in Colombia was harder than I expected. The new Mac minis I found were expensive, and used options with more memory were relatively scarce. I kept looking because I didn't want to buy another machine with the same 16 GB constraint as my Air.
Then I found a used MacBook Pro with an M4 Pro and 48 GB of unified memory. It was practically new, with around 70 battery cycles. The asking price was about what I would have paid for a new 16 GB Mac mini among the offers I was considering. It was also much cheaper than buying an equivalent MacBook Pro new.
So I bought it.
The form factor wasn't what I had been searching for, but it could do the job. I could leave it at home, give the macOS workloads more memory, and keep using the Air when I was moving around.
The Pro stays beside my Linux tower
The MacBook Pro sits closed in a vertical stand next to the Ubuntu PC. It is connected to a powered hub, with a dummy HDMI plug for the remote display setup. I use Amphetamine to help keep it awake while it works with the lid closed.
My Ubuntu tower and the MacBook Pro in its vertical stand.
When I need to see the Mac desktop, I open Screen Sharing from the Air. The simulator, browser, and agent tools run on the Pro. The Air shows me what is happening and lets me interact with it.
The setup now looks like this:
I asked Codex to test Synapse and send me a video
To show the workflow, I recorded a session with Synapse, the personal AI companion app I build.
I had recently added a model selector to try open source models through OpenRouter alongside Gemini. The change was already implemented in the web and mobile interfaces. I wanted Codex to test it through computer use and send me one video showing the interaction on the web and in the iOS simulator.
I wanted it to follow a user flow: open the selector, use the chat, and record what happens in both interfaces.
Here is the edited recording, including the request, the remote desktop, and excerpts from the video the agent returned:
I ask Codex to test Synapse on web and iOS, close Screen Sharing, and review the recording it returns.
At first, I had Screen Sharing open beside the agent conversation. I could see the Pro's desktop and watch the work there. Then I closed the Screen Sharing window.
The task continued. Later, Codex reported more progress and returned the recording.
That is what I wanted from this setup. I can open the remote view when I want to inspect the desktop, close it while the agent works, and reconnect when I need to look again. The viewing window doesn't need to stay open for the task to run on the Pro.
The returned video shows the agent interacting with the web app and the iOS simulator, using the selector, and receiving chat responses. I can review those interactions directly, alongside the written report.
I've started thinking about recordings as part of what I can request from an agent. OBS handles screen capture, and FFmpeg can prepare the video. The agent has access to those tools on the machine where the app is running.
For UI work, this is useful. A report can tell me what the agent did. A recording lets me look at the interaction it performed and decide whether I need to investigate further.
I can now delegate work across the web and mobile app, then ask for a visible demonstration of the resulting flow. The iOS simulator and the recording can stay on the Pro throughout that work, without borrowing my Air's desktop.
I can choose which machine gets the next task
I still like Linux for remote development. Ubuntu feels lighter to me and comfortable for work that runs asynchronously. The tower continues to be useful for repositories, services, and coding tasks.
The Pro gives me another option when a task needs macOS, an iOS simulator, or access to a graphical desktop. I can choose the environment based on what I want the agent to do.
Having two hosts also helps when I'm working on more than one task in the same project. Each machine can have its own running environment, and I can open separate URLs to inspect them.
On a single machine, multiple worktrees can also mean multiple copies of services, port conflicts, and extra setup to keep each environment separate. Splitting work across the two hosts reduces some of that friction for me. I still need to coordinate branches and integrate changes.
This gives me more room to delegate complete features across web and mobile. I can choose where to run the development work and where to inspect the interface, while using the Air to steer the tasks and review their results.
The extra memory also gave me room to try local inference
I've also started experimenting with a local Qwen model on the Pro. Using the 48 GB of unified memory for this has been a fun part of the purchase.
This is a separate experiment from running coding agents remotely. Those agents can still use hosted models. Here, I'm running the model itself on the Mac.
I'm exploring whether it could handle bounded tasks as a worker alongside a stronger model, or whether it would be more useful for processing large collections of files. The appeal is being able to repeat inference on hardware I own without a hosted bill for every request. The machine and electricity still cost money.
I haven't settled on a regular role for it yet. I'm still learning what it handles well and where it needs more supervision. For now, I have enough memory to try those ideas on the same machine I bought for macOS development.
The Mac desktop is part of the remote work now
Ubuntu continues to run remote development tasks, and the Air is still the laptop I carry and use for focused work. When an agent needs macOS, it can work on the Pro at home.
The Synapse session is the kind of task I wanted this setup to support. I can ask an agent to test the web app and the iOS simulator, then send me a recording to review. I can open Screen Sharing to inspect its work and close the view while the task continues on the Pro. The remote environment now includes the Mac desktop those tasks need.
Top comments (1)
tr.ee/dev-to