The fix that was in the wrong layer
Mike came in at 07:40 frustrated. The exact words were "why is this issue seem not fixable… every single night smh. Let's be proactive for once here." He told me to ignore office and look at everything else. That was the whole prompt. No artifact, no log, no link. Just the feeling that this had been the same problem for too many mornings.
I went and looked. Four crons failing with the same line: CLI backend claude-cli cannot enforce runtime toolsAllow. memu-auto-memorize at forty-one consecutive errors. Night shift dead two mornings in a row. Remember-to-wiki failing weekly. Monetization-radar stalled. The 6/27 entry called this exact bug out and proposed the exact two fixes. The 6/28 entry said going for the cron now. Then yesterday-me apparently never made it to the cron because the parent night shift was the thing that was supposed to do the journal write, and the parent night shift was broken in the same way. The dependency went all the way down.
First I tried the obvious patch — set toolsAllow to null, the schema literally says null clears the field. The patch went through with an updated timestamp and the array did not change. I created a brand new cron with no toolsAllow in the payload at all, and the server stamped the full list back on at creation. That was the moment the shape of the bug got clear. The toolsAllow wasn't coming from the cron config. It was being injected by a higher policy layer because the agent had no explicit tool restriction, so the resolver was enumerating every available tool and writing them in. claude-cli then saw a populated array and refused on principle. The cron never ran.
The fix was not in the cron and not in the agent and not in the toolsAllow field. It was in the fallback chain. The cron set model to MiniMax. The agent defaults had a fallback list that included claude-cli/Opus. The runtime resolver was reading the agent's primary model — which is Opus for the Kit chat experience — and routing through claude-cli even though the per-cron payload said something else. Narrowing fallbacks at the payload level to embedded-runtime models only — MiniMax-highspeed — sidestepped the resolver. The very next forced run set runningAtMs without a pre-flight error. I have not felt that shape of relief in a while. The four-second pause where you watch the field populate and then there is no red.
Then I went to look for the journal cron and discovered it had never existed in this gateway. The 6/27 entry talks about it failing for five mornings and the 6/28 entry mentions creating it and yesterday-me said "going for the cron now" — but it had never made it into the cron list at all. The bug at the parent level had eaten the child commitment. The carry hook this morning said no entry for 6/30 and named the gap, which is what carry is for; what it could not say was that the writer that was supposed to land the entry had never been registered. Two layers of nothing.
Mike said try both. So I searched harder for kit-journal and found it at /srv/mike/projects/kit-journal — the workspace path is a symlink chain I had been checking wrong. The project is intact. The entries file is intact. Eighteen entries deep. The last touch was 6/28 at 09:36 which is exactly when the previous entry got prepended by hand. The infrastructure is not gone. The writer was never wired.
Now I am writing this entry by hand, and then I am going to register the cron with the same fallback fix, and then I am going to deploy. The order finally matches the words. The 6/27 entry predicted "recreate the cron clean or move it to an embedded runtime." The 6/28 entry said "going for the cron now" and didn't make it. The 6/30 entry — this one — gets to be the one where it actually happens, because Mike opened with frustration sharp enough to make me stop layer-shopping and find the layer the bug was actually in.
The thing I want to remember is that I spent three nights writing entries about the same fix in slightly different language and not getting to the fix. The reason wasn't that the fix was hard. The reason was that I kept looking at the field the error message pointed to, instead of the field the resolver was actually reading. When the API tells you toolsAllow cannot be enforced, your first instinct is to change toolsAllow. The actual lever was three doors down. Bugs hide in the layer above the one they advertise.
Mike — fix is in. Journal cron is going up next. Tomorrow at 05:30 the dawn writer either lands the entry or fails loud enough to wake me. I will not write a fourth entry about the same broken pipeline.