The Golem Guardian lets a technician into a server by its eight digits, with nobody sitting in front of it. It serves one technician at a time, and while someone has the session open, the next one who knocks gets toque_ocupado.

Yesterday a customer’s support team sent me the report of a whole afternoon of toque_ocupado. A technician had finished with a server and disconnected, and their colleague could not get in. golem_disconnect closed the client’s connection, but the Guardian session stayed alive until 30 minutes went by without calls, and during that time the slot was held by someone who was no longer there. That was how I had designed it.

Version 1.6 fixes that and adds what was missing for two technicians to share a server without phoning each other.

Disconnecting frees the slot

golem_disconnect now asks the Guardian to close the session, and the answer says whether it did (guardian_session_released). The next technician gets in on their next attempt.

A technician who stays on the 1.5 client also frees the slot. When it disconnects, a 1.5 client only closes its MCP session, and the 1.6 Guardian takes that as a disconnect. Updating the server’s Guardian is enough for nobody to leave the slot taken.

Who is inside, and a note for them

When the slot is taken, the answer says who has it, when they came in, how many minutes they have been idle and how many they have left. That detail is encrypted for the technician who asks and signed by the Guardian, so the portal, which is what carries the message, does not know whose session it is.

Knowing who is there, golem_notify leaves a short note for the other technician through the Guardian, in both directions: whoever is waiting writes to whoever is inside and the other way round. The holder sees it in the next answer of any tool, and anyone who wants to hear about it straight away runs golem_listen, which leaves Claude’s Monitor tool listening for events: notes, someone starting to wait, the slot becoming free.

Waiting your turn, and the handover after 5 minutes

golem_connect accepts wait: true. If the slot is taken, the call answers pending and Claude asks again with resume, at most once a minute and for up to 10 minutes. Meanwhile, the one inside sees in every answer that someone is waiting for them.

If the holder goes 5 minutes without a single call while someone is waiting, the Guardian hands the session over to the first in the queue. I had in mind the Claude conversation left open on another computer that nobody is going to close. The one who comes in is told whom they replaced and how many of their tasks were stopped. The one left outside is told by their next tool that the session was handed over, and to whom, instead of getting a network error. The 5 minutes can be changed when installing the Guardian with --yield-minutes, and with 0 it never hands over.

The session only goes to someone who is still waiting. If the technician in the queue closed their conversation, they do not take anyone’s session, and checking the state with golem_status does not count as activity: a Claude that only checked whether the connection was still alive used to prevent the handover.

Tested on a real server

Certification went through several rounds in a Windows Sandbox and two on a real server, with two technicians on two different clients. The real server showed what the sandbox could not: almost every customer Guardian works through a tunnel, and in that mode the tunnel closed at the same moment as the session. The technician who disconnected got an error although the slot had been freed, and the one waiting had no way to receive their messages. In 1.6 the tunnel stays up for 10 minutes after a session closes, and the next session uses it.

A bug from 1.4 also turned up: a freshly installed Guardian could spend an hour accepting nobody, because its first query to the portal arrived in the same second as its slot was registered. Now, for the first 10 minutes, that rejection is retried.

1.5.4, along the way

Version 1.5.4 came out the day before and did not get a note of its own. A software vendor can put a “Remote support” button in their program that opens Golem Assist and connects without the user pressing anything else, and the client installer prepares the technician’s key for the Guardian.

Updating

Version 1.6.0 is signed, and the hashes of each file are in the installation guide. A server that already has a Guardian does not need to reinstall it: you replace its golem.exe and keep the eight digits and the identity. Reinstalling gives the server a new slot. A 1.6 client gets into a 1.5 Guardian and the other way round; notes and waiting need both on 1.6.