"Move to environment variable" action — convert a plaintext secret into a ${VAR} reference in place #83

New Issue

2026-07-20T13:46:49-04:00

the_og commented

2026-07-20 13:46:49 -04:00

Follow-up to #76, which lands the authoring and safety layer for ${VAR} references but no way to get one without typing it by hand.

What

After #76, BCC warns when a config holds a raw credential and points the user toward ${VAR}. It doesn't help them make the change. The gap is a one-click conversion:

In the env/headers table, on a row whose value looks like a secret: "Move to environment variable" → replaces the value with ${KEY_NAME} (defaulting the variable name to the row's key, editable).
Same on an args row that args_secret_warning flags.

The conversion itself is trivial; the useful part is that BCC then knows the variable name and can tell the user what to do next.

The bit that needs thought

Replacing the value deletes the actual secret from the config. If the user hasn't set the variable in their environment, the server stops working and the credential may be gone from the only place they had it.

So the action needs to hand the secret back before removing it — copy to clipboard, plus the exact shell line for their platform:

export GITHUB_TOKEN='ghp_...'        # macOS/Linux
setx GITHUB_TOKEN "ghp_..."          # Windows

Worth checking whether the variable is already set in BCC's environment and skipping the ceremony when it is.

Gating

Only offer this on profiles whose client expands references — client_expands_env_refs() from #76. Offering it on a Claude Desktop profile would walk the user into a broken config, which is the failure mode #76 exists to prevent.

Tests

The rewrite is pure (data in → data out) and belongs in bcc_core: value replaced with the right reference, variable name derived from the key and sanitised to a legal shell name, non-secret rows untouched, and the action refusing to fire on a non-expanding profile.

Follow-up to #76, which lands the authoring and safety layer for `${VAR}` references but no way to *get* one without typing it by hand. ## What After #76, BCC warns when a config holds a raw credential and points the user toward `${VAR}`. It doesn't help them make the change. The gap is a one-click conversion: - In the env/headers table, on a row whose value looks like a secret: **"Move to environment variable"** → replaces the value with `${KEY_NAME}` (defaulting the variable name to the row's key, editable). - Same on an args row that `args_secret_warning` flags. The conversion itself is trivial; the useful part is that BCC then knows the variable name and can tell the user what to do next. ## The bit that needs thought Replacing the value **deletes the actual secret from the config**. If the user hasn't set the variable in their environment, the server stops working and the credential may be gone from the only place they had it. So the action needs to hand the secret back before removing it — copy to clipboard, plus the exact shell line for their platform: ``` export GITHUB_TOKEN='ghp_...' # macOS/Linux setx GITHUB_TOKEN "ghp_..." # Windows ``` Worth checking whether the variable is already set in BCC's environment and skipping the ceremony when it is. ## Gating Only offer this on profiles whose client expands references — `client_expands_env_refs()` from #76. Offering it on a Claude Desktop profile would walk the user into a broken config, which is the failure mode #76 exists to prevent. ## Tests The rewrite is pure (`data` in → `data` out) and belongs in `bcc_core`: value replaced with the right reference, variable name derived from the key and sanitised to a legal shell name, non-secret rows untouched, and the action refusing to fire on a non-expanding profile.

the_og added the P2 label 2026-07-20 13:46:49 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: the_og/better-claude-config#83