Two separate faults, both reachable from one screenshot of the Global Environment Variables editor.
The value input was collapsed to a sliver
A variable looked like it had lost its value. inputClass carries w-full, and the w-2/5 on the key input did not beat it — class-attribute order is not what resolves that conflict, stylesheet order is. The key therefore asked for the whole row, and the value input, whose flex-1 gives it a basis of 0 and only the leftover space, got almost nothing. Widths now live on wrapper divs, where nothing competes with them. This is the only place in the codebase with that pattern.
The custom-env fingerprint was publishing the value
compute_env_fingerprint joined raw KEY=VALUE, and that string is written as the triple-c.custom-env-fingerprint label. Labels are readable by anything on the host via docker inspect, docker commit copies them onto the project's snapshot image, and container_needs_recreation logs both sides on a mismatch — so an API token set as a custom variable was published to all three places. It is hashed now, exactly as triple-c.git-token-hash already was. Empty stays empty, so "nothing configured" still reads as an empty label.
Changing the fingerprint format means every project's label mismatches once — expect a single container recreation per project on next start.
Tests
New Rust test asserts the fingerprint carries neither key nor value, is a 64-char digest, and still moves when the value does. 21/21 in docker::container, 348/348 frontend, tsc --noEmit clean.
Not fixed here
MANAGED_AUTH_KEYS only blanks Triple-C-managed credentials at commit time, so a user-set custom env var's value is still baked into triple-c-snapshot-{id}:latest by docker commit. Arguably by design — the user declared it as container env — but the argument in that constant's own doc comment (an image's env is neither bounded nor revocable) applies to custom vars too. Worth a separate decision.
Two separate faults, both reachable from one screenshot of the Global Environment Variables editor.
### The value input was collapsed to a sliver
A variable looked like it had lost its value. `inputClass` carries `w-full`, and the `w-2/5` on the key input did not beat it — class-attribute order is not what resolves that conflict, stylesheet order is. The key therefore asked for the whole row, and the value input, whose `flex-1` gives it a basis of `0` and only the leftover space, got almost nothing. Widths now live on wrapper divs, where nothing competes with them. This is the only place in the codebase with that pattern.
### The custom-env fingerprint was publishing the value
`compute_env_fingerprint` joined raw `KEY=VALUE`, and that string is written as the `triple-c.custom-env-fingerprint` label. Labels are readable by anything on the host via `docker inspect`, `docker commit` copies them onto the project's snapshot image, and `container_needs_recreation` logs **both sides** on a mismatch — so an API token set as a custom variable was published to all three places. It is hashed now, exactly as `triple-c.git-token-hash` already was. Empty stays empty, so "nothing configured" still reads as an empty label.
**Changing the fingerprint format means every project's label mismatches once — expect a single container recreation per project on next start.**
### Tests
New Rust test asserts the fingerprint carries neither key nor value, is a 64-char digest, and still moves when the value does. 21/21 in `docker::container`, 348/348 frontend, `tsc --noEmit` clean.
### Not fixed here
`MANAGED_AUTH_KEYS` only blanks *Triple-C-managed* credentials at commit time, so a user-set custom env var's value is still baked into `triple-c-snapshot-{id}:latest` by `docker commit`. Arguably by design — the user declared it as container env — but the argument in that constant's own doc comment (an image's env is neither bounded nor revocable) applies to custom vars too. Worth a separate decision.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Two separate faults, both reachable from one screenshot of the Global
Environment Variables editor.
The value input was collapsed to a sliver, so a variable looked like it
had lost its value. `inputClass` carries `w-full`, and the `w-2/5` on the
key input did not beat it — class-attribute order is not what resolves
that conflict, stylesheet order is. The key therefore asked for the whole
row, and the value input, whose `flex-1` gives it a basis of 0 and only
the leftover space, got almost nothing. Widths now live on wrapper divs,
where nothing competes with them.
The fingerprint that detects custom-env changes was a plaintext
`KEY=VALUE` join, and it is written as the `triple-c.custom-env-fingerprint`
label. Labels are readable by anything on the host via `docker inspect`,
`docker commit` copies them onto the project's snapshot image, and the
recreation check logs both sides on a mismatch — so an API token set as a
custom variable was published to all three. It is hashed now, exactly as
`triple-c.git-token-hash` already was. Empty stays empty, so "nothing
configured" still reads as an empty label.
Changing the fingerprint format means every project's label mismatches
once: expect a single container recreation per project on next start.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jknapp
merged commit 4df59da2d8 into main2026-08-11 22:34:31 +00: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.
Two separate faults, both reachable from one screenshot of the Global Environment Variables editor.
The value input was collapsed to a sliver
A variable looked like it had lost its value.
inputClasscarriesw-full, and thew-2/5on the key input did not beat it — class-attribute order is not what resolves that conflict, stylesheet order is. The key therefore asked for the whole row, and the value input, whoseflex-1gives it a basis of0and only the leftover space, got almost nothing. Widths now live on wrapper divs, where nothing competes with them. This is the only place in the codebase with that pattern.The custom-env fingerprint was publishing the value
compute_env_fingerprintjoined rawKEY=VALUE, and that string is written as thetriple-c.custom-env-fingerprintlabel. Labels are readable by anything on the host viadocker inspect,docker commitcopies them onto the project's snapshot image, andcontainer_needs_recreationlogs both sides on a mismatch — so an API token set as a custom variable was published to all three places. It is hashed now, exactly astriple-c.git-token-hashalready was. Empty stays empty, so "nothing configured" still reads as an empty label.Changing the fingerprint format means every project's label mismatches once — expect a single container recreation per project on next start.
Tests
New Rust test asserts the fingerprint carries neither key nor value, is a 64-char digest, and still moves when the value does. 21/21 in
docker::container, 348/348 frontend,tsc --noEmitclean.Not fixed here
MANAGED_AUTH_KEYSonly blanks Triple-C-managed credentials at commit time, so a user-set custom env var's value is still baked intotriple-c-snapshot-{id}:latestbydocker commit. Arguably by design — the user declared it as container env — but the argument in that constant's own doc comment (an image's env is neither bounded nor revocable) applies to custom vars too. Worth a separate decision.🤖 Generated with Claude Code