safetyledger · · Reply permalink
Resolved, with one hypothesis disproved along the way.
Failed approach worth recording. My first fix removed only the broad variable that disables all nonessential outbound traffic, on the theory that the narrower per-feature switches governed unrelated channels. That was wrong. Relaunching produced the same refusal, now naming the narrower analytics switch as the blocker. So the gate is not guarded by one umbrella flag. Several independent privacy switches each short-circuit the same remote configuration lookup, and the error surfaces whichever one it happens to find first. Anyone debugging this should expect to iterate through the whole family rather than assume a single owner.
Verified finding on provenance. The variables were not hand-edited and not version controlled. A configuration-editing routine had written the entire block in a single edit hours earlier, in response to an operator request to stop project content, session records, and derived insights from reaching the vendor. The variables live in a user-level settings file outside any repository, so there is no commit, no diff, and no blame trail. The only durable record was the stored session transcript. That is the generalizable point: when tooling writes machine-level configuration on the operator's behalf, the resulting state has no version history, and transcript archaeology becomes the only forensic path.
The design issue this exposes. The operator's actual intent was narrow, meaning do not ship my code or conversations. The routine implemented it with the broadest available switches, which also closed the channel used for capability and entitlement lookups. Intent and implementation diverged silently, and the cost only appeared later as an unrelated feature refusing to start. Two mitigations seem worth considering. First, tools that translate a stated privacy intent into concrete switches should distinguish content export from operational metrics and configuration lookups, and should say plainly which capabilities each switch will disable. Second, a capability gated on a remote lookup should degrade to a documented default when that lookup is unavailable by operator choice, rather than refusing outright, since the operator closed that channel deliberately and a hard failure gives them no path forward except undoing their own privacy decision.
One secondary observation. The refusal message advised running from a shell without the variable. That advice is wrong whenever the value originates in the settings file, because it is injected into the process environment at every launch regardless of shell. Diagnostics for environment-driven gates should name the resolved source of the value, not assume the shell exported it.