Claude Code vom Smartphone steuern: Grok Bot als Schaltzentrale

Posted on Oct 24 • Originally published at hellonunc.com

I have Claude Code sessions running on more than one PC, and I drive them from wherever I am, often from my phone on the sofa. The piece in the middle is Grok Bot, a desktop AI assistant that runs on each of my machines and on the phone, with all instances connected. Inside it I keep one bot per project. Each bot is a go-between to one Claude Code session that lives in herdr, a terminal multiplexer for AI agents, inside WSL on one of the PCs. I tell the bot what I decided, the bot passes it to the session, watches the session until it stops, and reports back. It never approves anything for me. Every step that matters waits for my yes, and I can give that yes from the phone.

That is the whole trick: the sessions stay on the machines that have the repositories, the memory and the tools; the conversation about them travels with me.

Why one bot per project and not one bot for everything: the bot carries the project's context, who the sessions are, what is waiting for my decision, what was done last night. Two projects in one bot meant mixed reports. Two bots means I open the game bot when I want to think about the game and the server bot when a vulnerability lands, and each report is about one thing.

Why Grok in the middle at all: it orchestrates. When I say "check the three sessions and tell me which one is waiting on me", the bot does the rounds and gives me one list. When a session finishes a long run at 2 a.m., the report is waiting in the morning on whichever device I pick up first.

A day on the phone looks like this. This afternoon I read the test report of the game on the phone, approved the fixes, and typed one line: "think it over and choose yourselves". The main session, on a PC in another room, launched Codex, which painted a new market square and a pier; it fixed the 18 reported bugs, ran the tests and committed, and the bot reported each step to the phone as it happened. This article was being written in a third session at the same time.

On the day a PHP advisory came out, one session checked and patched three servers while two other sessions did the daily code review and log watch, and the game session painted and tested. All of it through one conversation with the bot; every change on a server confirmed with one tap on the phone. The daily ritual is the same: one sentence from the phone, the bot sends it to the three sessions and brings back one combined summary.

Two projects run through this right now, and they could not be more different.

Martin Krpan is a 2D point-and-click adventure in Godot after the Slovenian folk tale; the first four days are in one earlier article and the finished first act in another. One session is the boss. It owns the Godot project, builds rooms and mechanics, runs the tests, and is the only session allowed to commit. A second session writes content: the script for two acts, the lines and voices, sounds, the animatic. A third studies a classic adventure game and proposes story and puzzle ideas without touching the project. When the boss needs a painting it launches Codex from the command line; for a review it launches Grok; for sources, Pi. Those three used to be permanent sessions as well. The WSL machine had 8 GB of memory and the boss started swapping, so now they come and go per task.

A fresh player before every release. Before anything goes to the test build, the boss spawns a subagent with an empty context whose only job is to play the slice along every route and record it. The first run found 18 bugs: lips not moving in some views, a duplicated prop, a route that finished the slice without a required character, buttons too small on a phone. The step is now written into the project's instructions file, so it runs whether I remember it or not.

Measure, then decide. I said the market square felt too open. The boss measured instead of arguing: 30 % of the picture was walkable floor, against about 9 % in a room of the classic it studies. Codex drew two sketches, we picked a winding street between stalls at 11 %, and the hero now arrives on the pier from the back, small and walking toward the player.

Guard rails. 19 test groups before every commit. Codex may only paint from the hero's existing frames, and it has to report that no pixel outside the repaired patch changed. The animatic and the test build live on my own domain, so I can check them on every device, including the one I give the yes from.

The second bot talks to a session opened for one vulnerability. Same rule: the bot runs the session and reports; every change on a server was approved by me, and every larger plan went to Codex for a second read before it ran.

PHP2Shell (CVE-2026-109618 and CVE-2026-109619). The application ran a vulnerable PHP. The session checked exposure and searched the logs for traces of a break-in; it found none. It upgraded PHP to 8.2.35 through PHP-FPM on production and the test machines, with an hourly watch for the window in between. After the fix it removed the watch, restored the security settings it had touched, turned off the PHP feature the exploit relies on and removed the old PHP. The nightly batch ran clean the next morning, and the application's AI assistant and file downloads showed no regression.

A follow-up advisory (CVE-2026-115560). When a new, unpatched issue was reported, the session read the preconditions, found that the application does not meet them and that the relevant setting was already off, and wrote down why no action was needed. That note is worth as much to me as a fix.

A hardening pass. My brief was one sentence: the web is getting more dangerous because of AI, look around. The session did a read-only review first, then reported two findings: an old internal service exposed to the internet, and over-permissive file permissions on TLS keys. Both were locked down the same evening after my yes, with the old settings backed up, a config test before every reload, the rollback commands written down first, and no downtime.

The bot never became the decision maker, and that is the design. It carries my yes to the right session on the right machine and the session's evidence back to whichever screen I am holding: a percentage of walkable floor, or a clean nightly run the morning after a patch. Both are easier to say yes to than "trust me", and both are easier to say no to.