The key here is that they are _not_ just turning "running codex on a VM" into an API. Their harness is running outside a VM, interacting with a VM when needed. See the diagram in their post. This allows them to scale the agent runs independently from the VMs. That's why they call it "managed Codex harness", it's a different version than what you run.
replyYes, I do the same with Claude Code. Create an instance on the server for a project and then can create sessions from any device, close my laptop while claude code keeps working, etc. without losing the convenience of dedicated apps.
replydeleted
replyI do the opposite. I have a Slack bot that communicates with an app on my Mac mini that dispatches agents for tasks. It knows all my projects and also has a scheduler that uses the Herdr API. That way I can have things running on my Claude/Codex subs at home 24/7.
replySetting up all my code, environment, context, etc in the cloud on VMs seemed like a lot so instead I send back tasks to my Mac mini(s) that are running at home.
Yep I run `claude remote-control` as daemons (systemd/launchctl) on whatever paths/repos I wanna be able to create a session from on-to-go.
replyWorks really well and is a great use case for work laptops. Same shell, same memories, same sessions
I've been running Hermes inside a remote docker container connected to Slack bound to a Codex account. It's actually pretty great, I prefer this approach for a lot of things. Because it's in a Docker container I have 100% control over the configuration. It may do some crazy stuff, but I know it's not going to start exfiltrating my AWS SSO tokens or SSH keys from my laptop.
replyI've done something similar by running pi within an xmpp wrapper on my server, so I can talk to it from any phone or computer. Works super well.
replyMay as well go for Hermes at that stage
replyDo you have 1 long running session?
replyConsidering the harness needs to be running how else would this work?
replyPretty easy these days with old school tools like tmux but more modern tooling like herdr [0] is really the path you'd want to take.
codex itself has a remote control mode that runs continuously. I wrote a systemd service to start it boot and interact with it via my phone.
replyBut Codex doesn't survive a reboot by default or a laptop going to sleep. Also, herdr is abstracted up a level from the agent, so you actually get more benefit by using Codex with herdr because herdr knows how to operate Codex, and other harnesses. So if you're using multiple Codex instances you can orchestrate them because each harness can talk to the others. You can still interact with Codex running in herdr via remote control (ideally you'd target your "orchestration" Codex instance). It just gives you way more power.
reply> Considering the harness needs to be running how else would this work?
replyyou can just make new sessions for each new task?
i tend to do this, or at least every so often.
replyi just give it a config (agents.md etc) to where it knows what's going on, or can figure it out
Codex remote control serve can run continuously.
replySometimes start a new chat in the phone app, sometimes just add to the main one. Both seem to work ok.
If I want the agent to wait for something I need to start a new chat in the iphone app.