fix(executor): give the workflow agent tool the caller's env and PII policy - #6611

Summary

A workflow attached as an Agent tool (workflow_executor) ran its entire child execution with environmentVariables: {} and no block-output PII redaction policy. The Pi block reaches the identical path (sim-tools.ts calls executeTool with executionContext: ctx), so it was affected the same way.

The failure was silent, and it leaked. With an empty env map the child's resolver cannot resolve {{MY_API_KEY}}, so EnvResolver returns the raw reference and the literal string {{MY_API_KEY}} is transmitted to the third-party API. The vendor 401s, the user sees an opaque auth error, and the variable name has already been handed to the vendor in an Authorization header or request body. Nothing in Sim reports "environment variable missing".

Separately, tenants who had explicitly enabled block-output PII redaction had it silently not applied to any child block in these runs.

Mechanism

buildCustomBlockExecutionContext hardcoded environmentVariables: {} when building the synthetic top-level ExecutionContext. That was safe for the branch it was written for: WorkflowBlockHandler.executeCore re-derives the publisher's env from getCustomBlockAuthority inside if (isCustomBlock), so the {} is provably overwritten before it is read.

The workflow-as-agent-tool path's synthetic block carries metadata.id: 'workflow_input' — it is not a custom block. It takes the non-custom branch, which keeps ctx.environmentVariables as-is, so the hardcoded {} flowed straight into the sub-Executor. Both fields landed as unnoticed side effects of #5273; #6539 later patched a third dropped field on the same context without noticing these two.

Fix

Thread both values through the runner options bag. executeTool reads them off the trusted executionContext, never params._context — that bag spreads model-reachable contextParams._context first, so sourcing from it would let a model inject its own env map or disable redaction. A test pins that a smuggled _context.environmentVariables is ignored.

Design decisions — please review these deliberately

environmentVariables is required, not optional-with-a-default. This is the entire recurrence guarantee. An empty env map is a wrong identity, not an absent value, and silent omission is exactly how this shipped — twice. Making it optional shortens the diff and re-arms the footgun; a future caller that forgets it is now a compile error.

piiBlockOutputRedaction stays optional. Here undefined genuinely is the correct value — most tenants have no policy at all. The asymmetry is intentional and documented in the TSDoc precisely so a future reader does not "unify" it.

deployed_block_executor deliberately receives neither value. Custom blocks skip the same-workspace assert and run cross-workspace under the publisher's identity, so the consumer's env and redaction rules would be the wrong tenant's. A test pins this so a later refactor cannot silently unify the branches.

Identity semantics — an honest note

This is not main's behavior, and it is not a strict subset of it. On main this tool was an HTTP hop into execution-core, which derived env from the child workflow's owner. This forwards the parent caller's map, matching the long-standing canvas workflow block (workflow-handler.ts keeps ctx.environmentVariables on the non-custom branch). It is a different identity, not a narrower one — chosen because it matches the canvas block byte-for-byte, is bounded to one workspace by assertChildWorkflowInWorkspace, and is the only variant consistent with the parent resolvedSecretTraceRegistry this path already forwards.

The narrow case that worked on main and still will not: a same-workspace child owned by another workspace member that relied on THAT member's personal environment variables.

⚠️ Release-note-worthy behavior change

Re-enabling block-output masking inside child runs means redaction now runs there with onFailure: 'throw' (block-executor.ts aborts rather than feed unmasked data downstream). For tenants who enabled block-output PII redaction, a child agent-tool call that succeeds unmasked today can now fail closed. That restores main's intended semantic — the control was always supposed to apply — but affected users will feel it as new failures.

Known gap, deliberately out of scope

tools/index.ts coalesces executionContext?.environmentVariables ?? {} because executionContext is optional on the options bag. /api/providers builds a runtime context without one and accepts a caller-supplied tools array, so a workflow_executor_<id> posted there would hit the same empty-map defect. No in-repo caller does this today, and closing it means changing executeTool's identity contract — its own change, not this one. enforceCredentialAccess is dropped by the same synthetic context and is likewise deferred: forwarding the parent's value would tighten behavior versus main and could break currently-working child runs mid-release.

Type of Change

• Bug fix

Testing

233 tests across 4 suites. Reverting the three source files turns exactly 5 red — including the model-smuggled-env-map test and the deployed_block_executor-exclusion test. Type-check and Biome clean.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)