GeezerVison

Fixes the remaining leak site from #3566.

What I observed

On a self-hosted v4 install, each runner container writes the whole startRunAttempt response body to stdout at the start of every attempt. WorkerApiRunAttemptStartResponseBody is StartRunAttemptResult & { envVars: z.record(z.string()) }, so that object contains the full project environment variable map. Redacted excerpt of a real runner log:

{"timestamp":"...","message":"started attempt","$name":"managed-run-logger","$level":"log",
 "start":{"envVars":{
   "DATABASE_URL":"postgresql://user:REAL_PASSWORD_WAS_HERE@db:5432/app",
   "SOME_PROVIDER_API_KEY":"REAL_KEY_WAS_HERE",
   "APP_SIGNING_SECRET":"REAL_SECRET_WAS_HERE"
 }, ...}}

Those values landed in every runner container's json log file, one entry per attempt.

Why the existing redaction doesn't catch it

SimpleStructuredLogger passes each line through redact() from packages/core/src/logger.ts, but filterKeys matches on the whole lowercased key name:

if (keys.has(key.toLowerCase())) { ... }

envVars isn't in DEFAULT_FILTERED_KEYS, so it's recursed into, and the user-defined names inside it (DATABASE_URL, SUPABASE_SERVICE_ROLE_KEY, …) match nothing in the list either. That leaves only SECRET_VALUE_PATTERN, which catches tr_*, sk-* and Bearer * — so a Postgres URL, a JWT-shaped service key, or a hex master key all pass through verbatim. The payload and metadata fields on the same object are filtered, which is why this is easy to miss.

ManagedRunLogger.sendDebugLog also forwards the same properties to the webapp debug-log endpoint via flattenAttributes, with no redaction on that path. It's gated behind TRIGGER_SEND_RUN_DEBUG_LOGS (default false), so it only leaks for operators who turned that on — but when they do, unredacted.

Why it matters for self-hosters

Runner stdout goes to whatever collects container logs (Loki, CloudWatch, Datadog, plain docker json files). Those pipelines are usually treated as low-sensitivity and are broadly readable, retained for weeks, and often shipped off-box. A task that needs any credential to do its job ends up publishing that credential there on every single attempt. LOG_LEVEL / DEBUG don't suppress it: sendDebugLog uses SimpleStructuredLogger.log, which is LogLevel.log = 0, the lowest value in the enum, so the if (this.level < LogLevel.log) return guard can never fire.

What I changed

execution.ts now logs an explicit projection instead of the raw response body — new executionLogging.ts, mirroring the buildWorkerLogging.ts split added in #4420 so the payload is unit-testable:

this.sendDebugLog("started attempt", startedAttemptLogProperties(start.data));

which yields run/snapshot identifiers, attempt number, task, queue, machine preset, and envVarKeys — the environment variable names only.

Two deliberate choices:

• Redact rather than remove. The entry is a useful "the attempt started, here is what it started with" marker, and the names answer the common question of whether a variable actually reached the runner. Only the values are dropped.
• Allow-list, not deny-list. envVars keys are user-defined, so no name-based deny-list can classify them — hence values are dropped wholesale rather than filtered. For the rest of the body an allow-list means a new field on the API response can't silently reintroduce a leak. This matches fix(cli): redact task run env values from debug log #4336, which fixed the equivalent leak in taskRunProcess.ts by logging Object.keys(fullEnv).

Since both sinks share one properties object, this fixes the stdout and webapp-endpoint halves together.

Scope

The other two sites named in #3566 are already handled on main, so this PR leaves them alone:

• taskRunProcess.ts — fixed by fix(cli): redact task run env values from debug log #4336 (released in 4.5.7); logs envKeys now.
• controller.ts — ...env.raw became ...env.rawForLogging, which redacts TRIGGER_DEPLOYMENT_ID. The rest is the bounded RunnerEnv zod schema, so no project secrets reach it.

One thing I noticed but did not touch, to keep this to a single issue: the debug-log HTTP sink in ManagedRunLogger.sendDebugLog flattens the raw mergedProperties, so it doesn't get the redact() pass that the stdout sink gets from SimpleStructuredLogger. Any other sendDebugLog caller that passes something sensitive is therefore protected on stdout but not on the wire. Happy to open a follow-up if you'd like that sink to redact too.

How I tested

• Added packages/cli-v3/src/entryPoints/managed/executionLogging.test.ts (4 tests, passing): asserts the serialized properties contain neither an env var value nor the run payload, that the env var names survive, the exact field set, and the envVars-absent case.
• Confirmed the test fails if the projection regresses — adding the raw body back to the returned object turns 2 of the 4 red.
• oxlint and oxfmt --check clean on the touched files.
• tsc -p tsconfig.src.json --noEmit reports the same 7 errors with and without this change (all from workspace packages I hadn't built), so no new type errors.
• I could not run snapshot.test.ts / taskRunProcess.test.ts in the same package: they need a built @trigger.dev/core, and building it needs Node 24, which I don't have locally. They fail identically on a clean checkout of main, so this change doesn't affect them, but I have not run the full cli-v3 suite.