Describe the bug
When an environment variable named with the TRIGGER_BUILD_ prefix is marked as Secret in the dashboard, GitHub-integration builds receive the literal string <redacted> as the variable's value instead of the stored secret.
The failure mode is very hard to diagnose: downstream consumers (e.g. git fetch against a private repo using the token) just see an invalid credential, which is indistinguishable from a mistyped token. We only found it by instrumenting the pre-build command to print the length and a sha256 fingerprint of the received value.
Reproduction steps
- Project deployed via the GitHub integration (native build server), preview environment.
- In the dashboard, create
TRIGGER_BUILD_MY_TOKEN, paste a valid token (93 chars), and check Secret.
- Add a pre-build command that prints safe diagnostics of the received value:
echo "token diag: len=${#MY_TOKEN} fp=$(printf %s "$MY_TOKEN" | sha256sum | cut -c1-12)"
- Push to trigger a deploy.
Observed (build log):
token diag: len=10 prefix=<redacted> whitespace=no fp=3a2d1afa44d1
remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentication failed for 'https://github.com/<org>/<private-repo>.git/'
The received value is 10 characters long and its sha256 matches the literal string <redacted> exactly:
$ printf %s '<redacted>' | sha256sum
3a2d1afa44d101200100d332f52384e523e7e881b7db0008da228cd94cebdfe1
Expected: the build receives the actual secret value (that's the only reason a build-time secret exists).
Additional confirmation
- Deleting every related variable → the build correctly sees the variable as unset (so the plumbing works).
- Recreating the exact same variable, same pasted value (clipboard length verified beforehand), but without the Secret flag → the build receives the real 93-char value and the deploy succeeds end to end.
- The Vercel env var sync was disabled during one of the secret-flagged attempts; same result, so it is unrelated.
Suspected cause
Build env vars for the GitHub build server appear to be sourced from a surface that redacts secrets. getEnvironmentWithRedactedSecrets in apps/webapp/app/v3/environmentVariables/environmentVariablesRepository.server.ts returns value: "<redacted>" for every isSecret: true variable (it backs the api.v1.projects.$projectRef.envvars.* routes). If the build pipeline reads variables through that path instead of resolving the secret store, every secret-flagged TRIGGER_BUILD_ variable silently becomes the placeholder.
Impact
Any secret needed at build time — private npm registry tokens (TRIGGER_BUILD_NPM_RC), private git/submodule fetch tokens, etc. — silently turns into <redacted> when the user does the natural thing and marks it as Secret. The resulting auth errors point the user at their token, not at Trigger.
Workaround
Create the TRIGGER_BUILD_ variable without the Secret flag.
Environment
- Trigger.dev Cloud, GitHub integration with the native build server
- Preview environment (branch deploys)
- Build log header:
Trigger.dev (4.4.6 -> 4.5.8)
- Observed on 2026-07-28
Describe the bug
When an environment variable named with the
TRIGGER_BUILD_prefix is marked as Secret in the dashboard, GitHub-integration builds receive the literal string<redacted>as the variable's value instead of the stored secret.The failure mode is very hard to diagnose: downstream consumers (e.g.
git fetchagainst a private repo using the token) just see an invalid credential, which is indistinguishable from a mistyped token. We only found it by instrumenting the pre-build command to print the length and a sha256 fingerprint of the received value.Reproduction steps
TRIGGER_BUILD_MY_TOKEN, paste a valid token (93 chars), and check Secret.Observed (build log):
The received value is 10 characters long and its sha256 matches the literal string
<redacted>exactly:Expected: the build receives the actual secret value (that's the only reason a build-time secret exists).
Additional confirmation
Suspected cause
Build env vars for the GitHub build server appear to be sourced from a surface that redacts secrets.
getEnvironmentWithRedactedSecretsinapps/webapp/app/v3/environmentVariables/environmentVariablesRepository.server.tsreturnsvalue: "<redacted>"for everyisSecret: truevariable (it backs theapi.v1.projects.$projectRef.envvars.*routes). If the build pipeline reads variables through that path instead of resolving the secret store, every secret-flaggedTRIGGER_BUILD_variable silently becomes the placeholder.Impact
Any secret needed at build time — private npm registry tokens (
TRIGGER_BUILD_NPM_RC), private git/submodule fetch tokens, etc. — silently turns into<redacted>when the user does the natural thing and marks it as Secret. The resulting auth errors point the user at their token, not at Trigger.Workaround
Create the
TRIGGER_BUILD_variable without the Secret flag.Environment
Trigger.dev (4.4.6 -> 4.5.8)