cli-env-var-verification

name	cli-env-var-verification
description	Verify that a CLI tool or daemon honors a specific environment variable before claiming the var 'works'. Combines four signals in priority order: (1) binary-string grep on the compiled executable as ground truth, (2) official vendor docs, (3) live process test, (4) confirm-the-var-in-config-file presence. Use when a user says 'does CLI X honor env var Y', 'test this env var with tool X', 'verify DISABLE_FOO_BAR=1 actually does something', 'why isn't setting this env var helping', or when about to commit an env var to a config file and need proof the tool respects it. The class failure mode is assuming a documented env var is real when it's only present in third-party blogs, or assuming the var works when the tool silently ignores it.
version	1.0.0
author	Hermes Agent
license	MIT
platforms	["macos","linux"]
metadata	{"hermes":{"tags":["verification","cli","environment-variables","debugging","ground-truth"],"related_skills":["github-pr-workflow","research-integrity"]}}

CLI env-var verification protocol

When a user asks "test env var X with tool Y" or you need to confirm a CLI tool actually honors a documented env var, do NOT stop at "the docs say it works" or "I set it and nothing broke". The bar is mechanically proving the tool reads the var at runtime.

Four signals, ordered by strength:

1. Binary string grep (ground truth)

The compiled executable contains every env var name it checks. If the var name appears as a literal string in the binary, the tool reads it. If not, the var is either ignored or undocumented.

# Example: verify Claude Code honors CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY
strings /path/to/cli/binary | grep -E "^ENV_VAR_NAME$"

# Watch for these patterns:
#   - Exact var name as a standalone line
#   - Internal event/feature-flag names that pair with it (e.g. tengu_feedback_survey_event
#     paired with CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY)
#   - Counterpart vars (ENABLE_*/DISABLE_*, *_FOR_OTEL) that confirm the family

Companion checks:

# For npm-installed packages:
strings $(which <tool>) | grep -E "^ENV_VAR_NAME$"

# For shell-script CLIs (no binary):
grep -rE "ENV_VAR_NAME" /usr/local/lib/<tool>/ 2>/dev/null

# For Python CLIs:
grep -rE "ENV_VAR_NAME|os\.environ|os\.getenv" /path/to/cli/source/ | head -20

This is the strongest signal because there's no interpretation layer between you and the code path. Verified 2026-07-10 with Claude Code's bin/claude.exe: literal strings CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY, CLAUDE_CODE_ENABLE_FEEDBACK_SURVEY_FOR_OTEL, and tengu_feedback_survey_event all appeared.

2. Official vendor docs

Cross-check that the var is documented by the tool's author, not just third-party blogs.

Search priority:

1. Tool's official docs site (e.g. docs.anthropic.com/en/docs/claude-code/...)
2. Tool's GitHub issues — search for the var name; issues referencing it confirm real-world use
3. Tool's output or page