Our scheduled job parsed the model's reply and found only a footer

I sent a headless AI call a plain prompt, “return this as JSON”, and the reply that came back was our own session footer. No JSON in it at all.

Why a scheduled job could read our footer

We run a lot of scheduled work through the command line version of Claude in non-interactive mode. Our machine has a hook that makes each reply end with a footer. A headless child process still loads this machine’s hooks and instruction files unless told not to, so the footer convention got reproduced in the result.

We reproduced it live before changing anything. The plain JSON prompt came back as pure footer text.

The only defense until then was a regex that stripped the footer off the result afterward. Stripping a footer from a reply that is nothing but a footer leaves nothing to parse. The riskiest caller was the job that reads our inbox and calendar. It parses the model’s JSON twice, then takes real actions on what it finds.

The flag, and the one we rejected

The fix is --safe-mode, which keeps the machine’s hooks and instructions out of the child process. We turned it on by default in the wrapper our scheduled calls already route through, so those callers were fixed without touching them. Four call sites spawn the CLI directly and bypass the wrapper, so each of them got the flag explicitly.

There was a tempting alternative, --bare. We rejected it because it forces an API key, and our rule is that background jobs only ever run on the prepaid plan and never touch a metered key. A flag that fixes the footer by moving the bill would have been the worse trade.

The lint that passed on a broken file

A fix like this decays the next time somebody writes a new spawn and forgets the flag. So we added a lint to our repo’s doc check: any file that starts a headless call without the flag fails the check.

Our first version searched the file’s text for the string --safe-mode. It missed a regression. The flag had been stripped from the real arguments and the check still passed, because a comment explaining the flag contained the string.

So the lint now parses the code and looks inside the enclosing function for the flag as an actual element of the argument list. Comments can’t satisfy it. We checked it both ways: it passes on the fixed tree, and it fails when we remove the flag with the explanatory comment still sitting there.

We also checked the fix against the original symptom. The same JSON prompt without the flag returned pure footer text, and with the flag it returned clean JSON.

A check that reads text can be satisfied by the sentence that explains the rule. That is why we now break the thing a guard protects before we trust the guard.

What to test

If an automated job parses AI output and then acts on it, find out whether a scheduled run inherits settings from the machine it runs on, and test with a deliberately broken setup. Any check that guards a fix has to be shown failing when the fix is removed. A check that cannot fail gives false assurance.

dxdev LESSON · paste into your AI coding agent
LESSON: A Lint That Reads Text Is Satisfied by the Comment That Explains the Rule
SOURCE: dxdev.com/blog/prompt-asked-for-json-came-back-a-footer
WHAT HAPPENED: Headless `claude -p` runs on our machine loaded our interactive hooks and instructions, so the footer our setup adds to every reply was reproduced in the result. A plain "return this as JSON" prompt came back as footer text with no JSON in it, which breaks any caller that parses the reply. The only defense had been a regex that stripped the footer afterward. The fix was the `--safe-mode` flag on every headless spawn. We added a lint requiring the flag on every call. The first version searched the file's text for the string "--safe-mode", and it still passed after we removed the flag from the real arguments, because a nearby comment explained the flag.
THE RULE: A lint that enforces an argument has to inspect the argument list in the syntax tree, not the text of the file. Prove any lint by breaking the thing it guards, with the explanatory comment still in place, and confirming it fails.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any headless model call whose result is parsed as JSON without an isolation flag that keeps your interactive hooks and instructions out of it.
  2. Any lint or test that checks for a flag or setting with a substring search over source text.
  3. Any guard that has never been shown to fail on the exact regression it exists to catch.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.