This is Episode 6 of The Vibe Coder’s Guide to the Machine: computer science for a new generation.
I built a small server on a Mac that hands out tokens, short pieces of text meaning roughly “whoever presents this may ask for data”. Each token carries its own deadline, four seconds after it is issued. A client program got one, saved it to a file, and sent it to the server once a second for seven seconds. At zero, one, two and three seconds, the server answered 200, “ok”. From the fourth second on, it answered 401, “token expired”. The client’s process ID was 91342 at the first call and 91342 at the last. It was the same healthy process the whole time, sending the same token.
What this shows is that a credential’s deadline is kept by the party that accepts it, not by the program holding it. So a program can keep running while what it holds stops counting. The question now is what actually fixes that, and what protects a program when the check is made by the holder.
Restarting is not renewal
Start with the token. When a program starts failing and nobody knows why, the reflex is to restart it, and often enough it seems to work. So after the client’s seven seconds, I started a new process from the same program, with process ID 91408. It read the token the first one had saved to the file, and it sent that token to the server. The answer was 401, “token expired”. The restart did not help.
It could not have helped, and the reason is worth following. A restart is a fresh process with a fresh memory, and whatever the old process held only in memory is gone. But this program kept its token in a file, on disk, exactly so that it would survive a restart. It did survive. The file outlived the process that wrote it, as a file does, and handed the next process a token whose deadline had already passed. A restart ends the holder and starts a new one. It never touches the clock, because that clock belongs to the server, not the program, and no restart of the program can move it.
Then I had the same program ask the server for a new token and call again. The answer was 200, “ok”. The code was not changed. The server was not changed. The only difference was a fresh token with a fresh deadline, issued by the party whose clock decides.
That is renewal: going back to whoever issued a credential and getting a new period of validity from them. A new period of validity comes only from the party that issues the credential, and the deadline is enforced by the party that accepts it. In my demonstration, one server did both. OAuth 2.0 builds this into the design. Alongside the access token, the server may issue a refresh token, a second credential whose job is to be exchanged for a new access token. One token does the work, and the other buys more time for the first. Renewal is a request to the party that issues the credential. Restarting is an action on your own machine. They get confused because they can look the same from outside, and here is how.
The first client process asked for a token when it started. Suppose the new one had done the same and ignored the file. Then the restart would have appeared to fix the problem: run it again, and the 401s go away. What actually fixed it would have been the request for a new token, which happened to sit in the start-up code. That is renewal by accident, and the price was throwing away everything the old process held in memory. It also teaches the wrong lesson, because the program will fail again at the next deadline, and the only cure it knows is to be restarted. This is why “it works after a restart” is such a poor diagnosis. It confirms that something during start-up fixed the problem. It does not say what.
A program that is meant to keep running needs renewal written into it. It needs to know which of its credentials have deadlines, ask for more time from the right party before or when they lapse, and decide what to do if the answer is no. An assistant will write that if you ask for it.
