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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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:${KEY_NAME}(defaulting the variable name to the row's key, editable).args_secret_warningflags.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:
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 (
datain →dataout) and belongs inbcc_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 referenced this issue2026-08-03 22:41:03 -04:00