fix(executor): keep resolved data out of the condition secret decision

The built script carries the source block's output as data, so scanning it
for placeholders let a caller choose which secret materializes beside its
own payload: `{{SECRET}}` in trigger data mounted that secret and had the
compiler expand it into the serialized context. Both scans now read the
expressions, which is where every legitimate route to a secret runs —
including a workflow variable holding `{{NAME}}`, since the resolver inlines
that value into the expression before this handler sees it.

`throw` joins the keywords a regex may follow. `throw /re/` is legal, and
without it the scan reads the pattern body as code and mis-reports the
context of everything after it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: icecrasher321

apps/sim/executor/handlers/condition/condition-handler.test.ts

@@ -232,10 +232,13 @@ describe('ConditionBlockHandler', () => {
     expect(toolParams.mountedSecrets).toEqual([])
   })
 
-  it('does not let resolved data widen the mounted secrets by naming the environment', async () => {
+  it('does not let resolved data decide which secrets the sandbox holds', async () => {
+    // The script carries the source block's output as data. Reading that data for either
+    // signal would let a caller pick what materializes beside it — the whole map by naming
+    // the global, or one secret by naming its placeholder.
     mockExecuteTool.mockResolvedValueOnce(matchedAt(0))
     mockContext.blockStates.set('source-block-1', {
-      output: { text: 'environmentVariables.OPENAI_API_KEY' },
+      output: { text: 'environmentVariables.OPENAI_API_KEY {{OPENAI_API_KEY}}' },
       executed: true,
       executionTime: 0,
     } as BlockState)
@@ -248,7 +251,7 @@ describe('ConditionBlockHandler', () => {
     await handler.execute(mockContext, mockBlock, { conditions: JSON.stringify(conditions) })
 
     const [, toolParams] = mockExecuteTool.mock.calls[0]
-    expect(toolParams.code).toContain('environmentVariables.OPENAI_API_KEY')
+    expect(toolParams.code).toContain('{{OPENAI_API_KEY}}')
     expect(toolParams.secretScope).toBe('selected')
     expect(toolParams.mountedSecrets).toEqual([])
   })

apps/sim/executor/handlers/condition/condition-handler.ts

@@ -97,23 +97,22 @@ function buildConditionScript(expressions: string[], evalContext: Record<string,
  * sandbox the full environment only widens what a future defect in this path could reach —
  * the whole map was readable as the `environmentVariables` global.
  *
- * The two scans read different text on purpose. Placeholders are read from the built script,
- * which is exactly what the compiler substitutes over, so a mounted set derived from anything
- * narrower would silently stop resolving a placeholder the compiler still expands. The direct
- * `environmentVariables` read is looked for in the expressions alone: the script also carries
- * the source block's output as data, so scanning that too would let a payload which merely
- * contains the word restore the full map.
+ * Both scans read the expressions rather than the built script, which also carries the source
+ * block's output as data. Reading that data would let it decide what the sandbox holds: a
+ * payload containing the word `environmentVariables` would restore the whole map, and one
+ * containing `{{SECRET}}` would mount that secret and have the compiler expand it into the
+ * data — a caller choosing which secret materializes next to it. Every legitimate route to a
+ * secret runs through an expression, including a workflow variable holding `{{NAME}}`, because
+ * the resolver inlines that value into the expression before this runs.
  *
- * Within an expression the bare identifier is enough, rather than a member access. Narrowing
- * the secrets an expression can see when it does reach for the map by some shape the pattern
- * did not anticipate — `environmentVariables?.FLAG`, or a read through `Object.keys` — would
- * route the run down a branch the author did not write, silently. Matching too widely only
- * costs the narrowing itself, and never mounts more than this path already mounted.
+ * Within an expression the bare `environmentVariables` identifier is enough, rather than a
+ * member access. Narrowing the secrets an expression can see when it does reach for the map by
+ * some shape the pattern did not anticipate — `environmentVariables?.FLAG`, or a read through
+ * `Object.keys` — would route the run down a branch the author did not write, silently.
+ * Matching too widely only costs the narrowing itself, and never mounts more than this path
+ * already mounted.
  */
-function scopeConditionSecrets(
-  code: string,
-  expressions: string[]
-): {
+function scopeConditionSecrets(expressions: string[]): {
   secretScope: 'all' | 'selected'
   mountedSecrets: string[]
 } {
@@ -122,8 +121,10 @@ function scopeConditionSecrets(
   }
 
   const named = new Set<string>()
-  for (const match of code.matchAll(createEnvVarPattern())) {
-    named.add(String(match[1]).trim())
+  for (const expression of expressions) {
+    for (const match of expression.matchAll(createEnvVarPattern())) {
+      named.add(String(match[1]).trim())
+    }
   }
   return { secretScope: 'selected', mountedSecrets: [...named] }
 }
@@ -144,7 +145,7 @@ async function runConditionCode(
   currentNodeId?: string
 ): Promise<ToolResponse> {
   const { blockNameMapping, blockOutputSchemas } = collectBlockData(ctx, currentNodeId)
-  const { secretScope, mountedSecrets } = scopeConditionSecrets(code, expressions)
+  const { secretScope, mountedSecrets } = scopeConditionSecrets(expressions)
 
   return executeTool(
     'function_execute',

apps/sim/executor/variables/resolver.ts

@@ -188,6 +188,7 @@ const JAVASCRIPT_REGEX_ALLOWED_AFTER_KEYWORDS = new Set([
   'delete',
   'void',
   'case',
+  'throw',
   'do',
   'else',
   'yield',