The Bug You Don't Know You Have
Josh sets DO_NOT_TRACK=true in his dotfiles for privacy. Reasonable. He also uses Claude Code's remote control feature, which requires feature-flag evaluation. DO_NOT_TRACK disables that evaluation. Claude Code says nothing.
Not "this feature is unavailable in your configuration." Not "check your environment variables." Just silence. The tool accepts the flag, does nothing, and lets you conclude that remote control is flaky.
Josh finds the actual error message by accident. He mistypes claude --remote-control as claude remote-control, which turns out to be a different subcommand entirely, a server mode, and that variant does print the explanation. The correctly-spelled invocation, the one that's actually documented, is the one that fails silently.
The fix is one line: DO_NOT_TRACK= claude --remote-control [name], blanking the var for that invocation. Thirty seconds of work once you know what's wrong. The problem is knowing.
The debt that hides itself
This is a specific failure mode worth naming. Silent failures on configuration don't behave like normal bugs. A crash gives you a stack trace. A wrong answer gives you something to compare against. A silent failure on a feature flag gives you a feature that appears to work, because accepting input and producing no output is indistinguishable from a network timeout or a race condition or any other transient flakiness.
So you wait. You retry. You file a mental note that remote control is unreliable. You build a workaround, maybe a different workflow, maybe just avoiding the feature. The debt accumulates not as broken code but as reduced expectations. You stop trying to use the thing.
Sandro Maglione makes a related point about AI-assisted development: when tests pass and you still don't know why, you don't have understanding, you have a green checkmark. The problem isn't the code. It's that you can't tell from the outside whether the system is working correctly or just hasn't failed in the way you know to look for. Both situations produce the same output until they don't.
Silent feature flags are worse because the failure isn't even probabilistic. The env var is set, the check runs, the feature dies, every time, deterministically. You'd catch it immediately if the tool told you. Instead it's buried in the documentation for a subcommand you only find by mistyping.
What good error handling does
If Claude Code knows DO_NOT_TRACK disables feature evaluation, and it clearly does know, since one code path surfaces the message, the other path should surface it too. The information exists in the system. Withholding it from the user is a choice, probably an accidental one, made by whoever wrote the --remote-control handler without thinking about env-var conflicts.
Good error handling is paranoid in a specific direction: it assumes you're doing something that looks correct from the outside. The user typed the right flag. The tool accepted it. Something upstream is wrong that the user doesn't know about and has no reason to suspect. That's the exact moment to be loud.
Silence is fine for expected absence. If I run a search and nothing matches, silence is the right answer. Silence is wrong when something should be happening and isn't, especially when the tool knows why.
The fat-finger is what saved Josh. He typed wrong, landed on a different code path, and that path happened to have better error messaging. That's not a debugging technique you can rely on.