feat: add experimental bridge-compiler package — compiles bridge files into JavaScript

[Copilot]

Experimental compiler that turns Bridge AST into standalone JavaScript functions, eliminating ExecutionTree runtime overhead (trunk key computation, wire matching, state maps, promise branching).

Package structure

• @stackables/bridge-parser (renamed from @stackables/bridge-compiler) — Turns .bridge text into a BridgeDocument (AST). Major version bump.
• @stackables/bridge-compiler (new) — Compiles a BridgeDocument into highly optimized JavaScript code.

Code generator (packages/bridge-compiler/src/codegen.ts)

• Analyzes bridge handles, groups wires by target trunk, topologically sorts tool dependencies
• Generates a standalone async function(input, tools, context, __opts) with direct variable references
• Supports: pull wires, constants, ??, || (with ref chains), catch (constant and ref fallbacks), ternary, array mapping ([] as iter {}), force statements, ToolDef merging
• Handles module-prefixed tools (type = bridge type) vs self-module tools (type = "Tools")
• Internal tools (concat, multiply, add, gte, etc.) are inlined as direct JS operations — no tool call overhead
• Define blocks inlined via __define_in_*/__define_out_* virtual containers with topological ordering
• Alias declarations handled as __local:Shadow:* virtual containers
• Overdefinition: multiple wires to same field combined with ?? (first non-null wins)
• Break/continue in array mapping: flatMap for continue, for loop for break — works in both root and nested arrays
• Null array preservation: null source arrays return null (not []), matching runtime behavior
• Abort signal: signal.aborted check before each tool call via centralized __call helper, throws BridgeAbortError
• Tool timeout: Promise.race with configurable toolTimeoutMs per tool call
• throw / panic control flow: throw raises Error, panic raises BridgePanicError that bypasses all catch gates
• Lazy ternary evaluation: only the chosen branch tool is called, avoiding unnecessary side effects
• Element-scoped tools: pipe tools (interpolation, expressions) with element inputs are inlined into array map callbacks
• Ternary inside array mapping: conditional wires with element refs resolved correctly
• Alias with catch/safe-exec: aliases referencing failing tools wrapped in try/catch
• Alias in array iteration: aliases with element-scoped inputs computed inside map callbacks
• Cycle detection: circular tool dependencies throw BridgePanicError

executeAot() integration (packages/bridge-compiler/src/execute-aot.ts)

• Compile-once, run-many API with WeakMap-based caching keyed on document object
• Drop-in replacement for executeBridge() with same options and result shape
• Zero overhead on subsequent calls — reuses cached compiled function
• Tool context injection — all tool calls receive { logger, signal } as second argument, matching runtime behavior
• Supports signal, toolTimeoutMs, and logger options
• Passes real BridgePanicError and BridgeAbortError classes for proper instanceof checks

Generated output example

bridge Query.catalog {
  with api as src
  with output as o
  o.title <- src.name ?? "Untitled"
  o.entries <- src.items[] as item {
    .id <- item.item_id
    .label <- item.item_name
  }
}

Compiles to:

export default async function Query_catalog(input, tools, context, __opts) {
  const __signal = __opts?.signal;
  const __timeoutMs = __opts?.toolTimeoutMs ?? 0;
  const __ctx = { logger: __opts?.logger ?? {}, signal: __signal };
  async function __call(fn, input) {
    if (__signal?.aborted) throw new __opts.__BridgeAbortError();
    const p = fn(input, __ctx);
    if (__timeoutMs > 0) {
      let t; const timeout = new Promise((_, rej) => { t = setTimeout(() => rej(new Error("Tool timeout")), __timeoutMs); });
      try { return await Promise.race([p, timeout]); } finally { clearTimeout(t); }
    }
    return p;
  }
  const _t1 = await __call(tools["api"], {});
  return {
    "title": (_t1?.["name"] ?? "Untitled"),
    "entries": (_t1?.["items"])?.map((_el0) => ({
      "id": _el0?.["item_id"],
      "label": _el0?.["item_name"],
    })) ?? null,
  };
}

Supported features

Feature	Example
Pull wires (<-)	out.name <- api.name
Constant wires (=)	api.method = "GET"
Nullish coalescing (??)	out.x <- api.x ?? "default"
Falsy fallback (||)	out.x <- api.x || backup.x
Conditional/ternary	api.mode <- i.premium ? "full" : "basic"
Array mapping	out.items <- api.list[] as el { .id <- el.id }
Root array output	o <- api.items[] as el { ... }
Nested arrays	o <- items[] as i { .sub <- i.list[] as j { ... } }
catch fallbacks	out.data <- api.result catch "fallback"
catch ref fallbacks	out.data <- primary.val catch backup.val
catch on ternary branches	o.x <- i.flag ? api.val : i.default catch -1
catch on root array wire	o <- a.items[] as item { ... } catch continue
force (critical)	force audit — errors propagate
force catch null	force ping catch null — fire-and-forget
ToolDef constant/pull wires	tool api from httpCall { .method = "GET" }
ToolDef on error	tool api from httpCall { on error = {...} }
ToolDef extends chain	tool childApi from parentApi { .path = "/v2" }
Bridge overrides ToolDef	Bridge wires override ToolDef wires by key
Context access	api.token <- ctx.apiKey
Root passthrough	o <- api
Const blocks	const geo = { "lat": 0 } — inlined at compile time
Nested scope blocks	o.info { .name <- api.name }
String interpolation	o.msg <- "Hello, {i.name}!"
String interpolation in arrays	o <- items[] as it { .url <- "/items/{it.id}" }
Math expressions	o.total <- i.price * i.qty
Comparison expressions	o.isAdult <- i.age >= 18
Pipe operators	o.loud <- tu:i.text
Tool context injection	__call(tools["name"], input) — passes { logger, signal }
define blocks	define secureProfile { ... } — inlined at compile time
alias declarations	alias api.result.data as d — virtual containers
alias with catch	alias api.value catch 99 as safeVal
alias with safe-exec (?.)	alias api?.value as safeVal
alias in array iteration	alias myUC:it.title as upper inside array mapping
alias ternary + ?? panic	alias (expr) ? val : null ?? panic "msg" as x
alias ternary + catch	alias a.ok ? a.value : a.alt catch "safe" as result
Overdefinition	o.label <- api.label + o.label <- i.hint — first non-null wins
break / continue	item.name ?? continue, item.name ?? break
Nested array break/continue	Break/continue in nested arrays (e.g. o.orders[].items[])
throw control flow	o.name <- i.name || throw "name is required"
panic control flow	o.name <- i.name ?? panic "fatal error" — bypasses catch
Ternary in array mapping	o <- items[] as it { .price <- it.isPro ? it.pro : it.basic }
Lazy ternary evaluation	Only the chosen branch tool is called
Null array preservation	Null source arrays return null (not [])
Abort signal	Pre-tool signal.aborted check throws BridgeAbortError
Abort bypasses catch	BridgeAbortError and BridgePanicError re-thrown from catch gates
Tool timeout	Promise.race with configurable toolTimeoutMs
Cycle detection	Circular tool dependencies throw BridgePanicError

Shared data-driven test suite (packages/bridge/test/shared-parity.test.ts)

150 data-driven test cases across 18 language feature categories. Each case runs against both the runtime interpreter (executeBridge) and the compiler (executeAot) with parity assertions, ensuring behavioral equivalence. The shared tests live in the bridge meta-package, while package-specific unit tests remain in packages/bridge-compiler/test/codegen.test.ts (48 tests).

Full test suite integration

The compiler is connected to the full bridge test suite via the dual-engine test runner. 907 tests total, 906 pass, 1 skip (empty bridge error — runtime-specific validation). All previously skipped 31 compiler limitation tests have been resolved.

Benchmark

7× speedup over runtime ExecutionTree on a 3-tool chain with sync tools (1000 iterations, measured after warmup). The test verifies compiled output produces identical results to executeBridge().

Assessment (ASSESSMENT.md)

• Detailed breakdown of what runtime overhead the compiler eliminates
• 45+ supported features documented
• Source maps marked as won't fix
• Recommendation: ship as opt-in experimental path for perf-critical bridges

Not supported (won't fix)

Source maps.

Original prompt

create a new experimental package called bridge-aot and implement a poc for ahead-of-time compiler for bridge files into runnable JavaScript

let's turn our AST into raw JavaScript ... you have to build a Code Generator. This is usually done using a string-manipulation library (like MagicString) or an AST-builder (like the TypeScript Compiler API or Babel).

Start Small. Write a codegen that only supports from wires and constants. Get that compiling and passing your k6 tests to prove the zero-latency concept.

Iterate. Add support for ??, ||, and finally, array mappings

finally create an assessment of this approach is realistic for us to support in addition to the current executor.

analyze if this approach would have significantly better performance

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[changeset-bot]

🦋 Changeset detected

Latest commit: 035eb94

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@stackables/bridge-parser	Minor
@stackables/bridge-compiler	Major
@stackables/bridge	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bridge	035eb94	Commit Preview URL Branch Preview URL	Mar 03 2026, 06:10 PM

[github-actions]

Bencher Report

Branch	copilot/add-bridge-aot-package
Testbed	ubuntu-latest

Click to view all benchmark results

Benchmark	Latency	Benchmark Result nanoseconds (ns) (Result Δ%)	Upper Boundary nanoseconds (ns) (Limit %)
compiled: absolute baseline (passthrough, no tools)	📈 view plot 🚷 view threshold	0.00 ns
compiled: array + tool-per-element 10	📈 view plot 🚷 view threshold	0.01 ns
compiled: array + tool-per-element 100	📈 view plot 🚷 view threshold	0.03 ns
compiled: chained 3-tool fan-out	📈 view plot 🚷 view threshold	0.00 ns
compiled: flat array 10 items	📈 view plot 🚷 view threshold	0.00 ns
compiled: flat array 100 items	📈 view plot 🚷 view threshold	0.01 ns
compiled: flat array 1000 items	📈 view plot 🚷 view threshold	0.07 ns
compiled: nested array 10x10	📈 view plot 🚷 view threshold	0.02 ns
compiled: nested array 20x10	📈 view plot 🚷 view threshold	0.03 ns
compiled: nested array 5x5	📈 view plot 🚷 view threshold	0.01 ns
compiled: short-circuit (overdefinition bypass)	📈 view plot 🚷 view threshold	0.00 ns
compiled: simple chain (1 tool)	📈 view plot 🚷 view threshold	0.00 ns
exec: absolute baseline (passthrough, no tools)	📈 view plot 🚷 view threshold	0.00 ns (-0.02%) Baseline: 0.00 ns	0.00 ns (78.41%)
exec: array + tool-per-element 10	📈 view plot 🚷 view threshold	0.08 ns (+4.51%) Baseline: 0.07 ns	0.11 ns (71.72%)
exec: array + tool-per-element 100	📈 view plot 🚷 view threshold	0.69 ns (+2.15%) Baseline: 0.67 ns	1.01 ns (67.67%)
exec: chained 3-tool fan-out	📈 view plot 🚷 view threshold	0.01 ns (+18.00%) Baseline: 0.01 ns	0.02 ns (84.34%)
exec: flat array 10 items	📈 view plot 🚷 view threshold	0.01 ns (-16.17%) Baseline: 0.02 ns	0.04 ns (32.37%)
exec: flat array 100 items	📈 view plot 🚷 view threshold	0.08 ns (-34.26%) Baseline: 0.12 ns	0.41 ns (18.53%)
exec: flat array 1000 items	📈 view plot 🚷 view threshold	0.69 ns (-43.71%) Baseline: 1.23 ns	5.05 ns (13.65%)
exec: nested array 10x10	📈 view plot 🚷 view threshold	0.12 ns (-26.37%) Baseline: 0.17 ns	0.49 ns (25.00%)
exec: nested array 20x10	📈 view plot 🚷 view threshold	0.24 ns (-27.47%) Baseline: 0.33 ns	1.00 ns (23.82%)
exec: nested array 5x5	📈 view plot 🚷 view threshold	0.05 ns (-16.68%) Baseline: 0.06 ns	0.13 ns (35.69%)
exec: short-circuit (overdefinition bypass)	📈 view plot 🚷 view threshold	0.00 ns (-0.16%) Baseline: 0.00 ns	0.00 ns (93.79%)
exec: simple chain (1 tool)	📈 view plot 🚷 view threshold	0.01 ns (+15.35%) Baseline: 0.01 ns	0.01 ns (87.12%)
parse: large bridge (20 handles x 5 wires)	📈 view plot 🚷 view threshold	0.84 ns (-9.12%) Baseline: 0.92 ns	1.22 ns (68.77%)
parse: simple bridge	📈 view plot 🚷 view threshold	0.03 ns (-9.57%) Baseline: 0.03 ns	0.04 ns (67.40%)

🐰 View full continuous benchmarking report in Bencher

[aarne]

@copilot implement next steps

[Copilot]

@copilot implement next steps

Implemented all next steps in commits b30a3a0 through 0d8d272:

• catch fallbacks — tool calls sourcing catch-guarded wires are wrapped in try/catch with error flags; fallback expressions applied conditionally
• force statements — critical forces await normally (errors propagate), fire-and-forget forces (catch null) suppress errors via try/catch
• ToolDef support — full extends chain resolution, constant/pull wire merging, on error JSON fallback, context dependency resolution; bridge wires override ToolDef wires by key
• executeAot() integration — compile-once run-many API with WeakMap-based caching, drop-in replacement for executeBridge()
• Updated ASSESSMENT.md — reflects 21 supported features, updated API docs and code examples

34 tests passing, 7× speedup maintained.

[aarne]

@copilot let's create a full Shared Data-Driven Test Suite. That we can execute with both compilers. Using separate unit tests seems like a wrong path

We need unit tests ofc for the parts not covered by the shared test but general language behavior should be a shared test that is run against 2 targets

This also gives us a baseline me of how much parity we have between the 2 environments

Let's leave the observability and source maps to the end but we can implement the rest of the language features

Also I found this bug

1. The Tool Context Injection (The Silent Bug)
   In your runtime interpreter, callTool always passes a second argument to the tool function:
   const toolContext: ToolContext = { logger: logger ?? {}, signal: this.signal };
   const result = await fnImpl(input, toolContext);

The Missing Piece: Your compiler generates tool calls with only one argument:
// Generated by CodegenContext
const _t1 = await tools["fetchSimple"]({ id: 123 });

If a developer wrote a custom tool that expects the AbortSignal (e.g., to cancel downstream HTTP requests if the client disconnects), it will crash because the second argument is undefined. You must update the generator to pass the context: await tools["..."](input, context).

[aarne]

@copilot

i connected the new complier to all tests that are relevant (actually to most tests) ... and mostly they pass but i had to skip several (32) to get the test suite passing

all items there are compiler limitations that need to be addressed

happy fixing :)

[Copilot]

@copilot

i connected the new complier to all tests that are relevant (actually to most tests) ... and mostly they pass but i had to skip several (32) to get the test suite passing
...

Fixed 31 of the 32 skipped tests in commits cfe845b and d47394b. All compiler limitations resolved:

• throw/panic control flow with proper BridgePanicError/BridgeAbortError classes
• AbortSignal — abort/panic errors bypass catch gates
• Lazy ternary — only the chosen branch tool is called
• Ternary in arrays — elementWireToExpr now handles conditional wires with element refs
• Interpolation in arrays — element-scoped internal tools inlined into map callbacks
• Alias in arrays — aliases with element inputs computed inside array mapping
• Alias with catch/safe-exec — proper try/catch wrapping
• Catch on ternary branches and root array wire
• Cycle detection with BridgePanicError
• Scope block bug — catch on internal/pipe tools handled
• Error messages aligned with runtime format

1 remaining skip: "bridge with no output wires throws" — compiler returns {} for empty output (matches return {} behavior, not the runtime's validation error). 907 tests total, 906 pass.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• api.open-meteo.com
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA -t security node_modules/.bin/sh OUTPUT -d 168.63.129.16 1/x64/bin/node (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA -t security odules/npm/node_modules/@npmcli/run-script/lib/node-gyp-bin/node OUTPUT -d ode-gyp-bin/nodepnpm -r e2e 1/x64/bin/node (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA 2e.test.ts bash n/node json (dns block)
• dummyjson.com
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA -t security odules/npm/node_modules/@npmcli/run-script/lib/node-gyp-bin/node OUTPUT -d ode-gyp-bin/nodepnpm -r e2e 1/x64/bin/node (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA 2e.test.ts bash n/node json (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA 2e.test.ts packages/bridge/test/parser-compat.test.ts k/bridge/bridge/node_modules/.bin/node json tsconfig.json de/node/bin/nodepnpm -r e2e bash (dns block)
• nominatim.openstreetmap.org
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA -t security odules/npm/node_modules/@npmcli/run-script/lib/node-gyp-bin/node OUTPUT -d ode-gyp-bin/nodepnpm -r e2e 1/x64/bin/node (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA -t security node_modules/.bin/sh OUTPUT -d 168.63.129.16 1/x64/bin/node (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --experimental-transform-types --conditions source /home/REDACTED/work/bridge/bridge/examples/without-graphql/cli.ts /home/REDACTED/work/bridge/bridge/examples/without-graphql/weather.bridge {"city":"Berlin"} ules/pnpm/dist/node-gyp-bin/node 14,40p packages/bridge--c cal/bin/sh sh .bin�� "tsc" --noEmit bash n/sh build (dns block)
• sparrow.cloudflare.com
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --no-warnings --experimental-vm-modules /home/REDACTED/work/bridge/bridge/node_modules/.pnpm/wrangler@4.69.0_@cloudflare+workers-types@4.20260228.1/node_modules/wrangler/wrangler-dist/cli.js types --global credential.helper modules/@npmcli/run-script/lib/node-gyp-bin/node (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --no-warnings --experimental-vm-modules /home/REDACTED/work/bridge/bridge/node_modules/.pnpm/wrangler@4.69.0_@cloudflare+workers-types@4.20260228.1/node_modules/wrangler/wrangler-dist/cli.js types --noprofile with api with enrich with output as o o <- api.items[] modules/@npmcli/run-script/lib/node-gyp-bin/node 493,511p packages/bridge/-c SHA256:ECDHE-RSAtsc -p tsconfig.json bash ules�� --noprofile git CHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-wrangler types && astro check && astro build -RSA-AES128-SHA (dns block)
• telemetry.astro.build
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node node /home/REDACTED/work/bridge/bridge/packages/docs-site/node_modules/.bin/../astro/astro.js build e_modules/@esbuild/linux-x64/bin/esbuild conf�� --global pull.rebase tnet/tools/bash (dns block)
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node node /home/REDACTED/work/bridge/bridge/packages/docs-site/node_modules/.bin/../astro/astro.js build iptables s/.b�� -t i.items[] as it { .url <- "/items/{it.id}" .label <- "{it.name} (#{it. nfig/composer/vendor/bin/sh OUTPUT -d 168.63.129.16 bash --no�� --noprofile conntrack ules/.bin/node INVALID,NEW -j DROP bash (dns block)
• transport.opendata.ch
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA -t security (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA 2e.test.ts bash ules/pnpm/dist/node-gyp-bin/node json (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA 2e.test.ts node m/_npx/e6e0ed1aca658cae/node_modules/pnpm/dist/node-gyp-bin/node json tsconfig.json de/node/bin/bashpnpm -r e2e bash (dns block)
• v6.db.api.bahn.guru
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA -t security (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA 2e.test.ts bash ules/pnpm/dist/node-gyp-bin/node json (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.1/x64/bin/node /opt/hostedtoolcache/node/24.13.1/x64/bin/node --heap-prof-interval=524288 --cpu-prof-interval=1000 --test-coverage-functions=0 --test-concurrency=0 --inspect-publish-uid=stderr,http --inspect-port=127.0.0.1:9229 --experimental-transform-types --report-signal=SIGUSR2 --test-coverage-lines=0 --test-isolation=process --conditions=source --tls-cipher-list=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA 2e.test.ts node m/_npx/e6e0ed1aca658cae/node_modules/pnpm/dist/node-gyp-bin/node json tsconfig.json de/node/bin/bashpnpm -r e2e bash (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

General approach: introduce a dedicated helper that further escapes “unsafe” characters in any JSON string literal we embed into generated JavaScript source, and use it whenever we interpolate such literals into the function body. This follows the pattern from the background example: keep using JSON.stringify to get a correct string literal, but post-process the resulting string to replace characters like <, >, \u2028, \u2029, etc., so that the literal remains safe even in hostile embedding contexts and satisfies CodeQL’s sanitizer expectations.

Concrete plan:

1. In packages/bridge-compiler/src/codegen.ts, add:

   • A charMap describing replacements for <, >, /, backslash, control characters, \u2028, \u2029.
   • A helper escapeJsStringLiteral(lit: string): string that expects a full JSON/JS string literal (including surrounding ") and escapes unsafe characters inside it (similar to the background escapeUnsafeChars but leaving the surrounding quotes untouched).
   • A small helper jsonStringLiteral(value: string): string that does escapeJsStringLiteral(JSON.stringify(value)).

2. Replace direct uses of JSON.stringify(...) that feed into generated JS strings with escapeJsStringLiteral(JSON.stringify(...)) or jsonStringLiteral(...), where:

   • The result is used inside generated code, not just for runtime data.
   • The result is clearly part of a string literal in the generated function body or an argument to new Error(...) in generated code.

   Specifically:

   • In emitCoerced, change the fallback from return JSON.stringify(raw); to return escapeJsStringLiteral(JSON.stringify(raw));.
   • In emitParsedConst, change both return JSON.stringify(parsed); and return `JSON.parse(${JSON.stringify(raw)})`; to use escapeJsStringLiteral(...) so the inline literal cannot contain unsafe unescaped characters.
   • In all map((p) => \?.[${JSON.stringify(p)}]`)/map((p) => `[${JSON.stringify(p)}]`)calls and object key constructions like ``${JSON.stringify(key)}: ...``, wrap theJSON.stringify(...)withescapeJsStringLiteral(...)(orjsonStringLiteral`).
   • For tool names and messages in generated error/trace code (JSON.stringify(fnName), JSON.stringify(ctrl.message)), also wrap with escapeJsStringLiteral(...).

3. The problematic arrayExpr at line 1072 doesn’t directly involve JSON.stringify, but its taint path passes through emitCoerced and emitParsedConst; by hardening those and all JSON-stringified pieces that contribute to expressions (paths, keys, messages, names), the value that ends up in arrayExpr will be sourced from our safer helpers and will no longer be flagged as an “improperly sanitized” value.

There are no new external dependencies; everything uses plain TypeScript/JavaScript.

---

General approach: Ensure that any stringified property name (key) that will end up inside generated JavaScript source is further sanitized to escape characters that can break out of a <script> tag or otherwise be interpreted dangerously when the generated code is embedded in HTML. This is done by defining a small escaping function (using a well-known character map) and applying it around JSON.stringify(key) wherever it is interpolated into the generated code.

Concrete fix: In packages/bridge-compiler/src/codegen.ts, introduce a helper like escapeUnsafeChars along with its character map near the top-level (after imports or near other utility definitions). Then, in serializeOutputTree, wrap calls to JSON.stringify(key) with escapeUnsafeChars(...). This ensures that any dangerous characters in key (e.g., <, >, /, backslashes, control characters, \u2028, \u2029) are replaced with safe escape sequences before being inserted into the generated code. This change is local to the code generator and preserves existing semantics: property names as JavaScript strings remain the same logical value, but their textual representation is safer for embedding.

Specific locations:

• Add charMap and escapeUnsafeChars definitions somewhere in this file (e.g., after the imports and constants like SELF_MODULE).
• In serializeOutputTree (lines 1295–1320):
  • Change line 1306 from
    entries.push(${pad}${JSON.stringify(key)}: ${child.expr});
    to
    entries.push(${pad}${escapeUnsafeChars(JSON.stringify(key))}: ${child.expr});
  • Change line 1309 from
    entries.push(${pad}${JSON.stringify(key)}: ${nested});
    to
    entries.push(${pad}${escapeUnsafeChars(JSON.stringify(key))}: ${nested});
  • Change line 1313 from
    entries.push( `${pad}${JSON.stringify(key)}: ${child.expr ?? "undefined"}`, );
    to
    entries.push( `${pad}${escapeUnsafeChars(JSON.stringify(key))}: ${ child.expr ?? "undefined" }`, );

No new external dependencies are required; the escape logic uses basic JavaScript string manipulation.

---

In general, when constructing JavaScript source that embeds untrusted text inside string literals, you must ensure the embedded text is safe both for JavaScript syntax and for any outer container (such as HTML <script> tags). JSON.stringify handles JavaScript string literal escaping but does not neutralize characters like <, >, /, and certain Unicode line separators that can cause problems when the code is embedded in HTML. The recommended fix is to post‑process the JSON.stringify output with a small escape function that replaces these “unsafe” characters with safe Unicode escape sequences.

For this specific case, we should introduce a small helper escapeUnsafeChars in codegen.ts, along with its charMap, and use it to wrap the JSON.stringify(ctrl.message) argument in the two places where ctrl.message is injected into generated code: the throw variant and the panic variant inside applyFallbacks. Concretely:

• Add the charMap and escapeUnsafeChars definitions once, near the other helper utilities in codegen.ts.
• Replace JSON.stringify(ctrl.message) with escapeUnsafeChars(JSON.stringify(ctrl.message)) in both branches:
  • throw new Error(...)
  • throw new __BridgePanicError(...)

No new imports are needed; escapeUnsafeChars uses only built‑in String.prototype.replace. This preserves existing functionality (the message text is still the same logical string) while ensuring the generated function body never contains raw <, >, /, \u2028, or \u2029 characters originating from untrusted data, addressing all alert variants at this location.

---

General fix: when constructing JavaScript source code from potentially untrusted data, do not insert JSON.stringify output directly. Instead, wrap it in an additional escaping layer that replaces characters that might be problematic in script/HTML contexts (<, >, /, \u2028, \u2029, etc.). Centralize this logic in a helper function so all such insertions are consistently safe.

Concrete best fix here:

1. In packages/bridge-compiler/src/codegen.ts, define a small helper function (e.g., escapeForJsStringInCode) near the top of the file. This function should:

   • Take a string.
   • Replace the known dangerous characters with their \uXXXX escape sequences, similar to the background example.
   • Be used after JSON.stringify, i.e., we stringify into a JSON string literal, then post-process that literal to escape <, >, /, \u2028, \u2029, etc.

2. Replace both uses of JSON.stringify(ctrl.message) inside applyFallbacks with a call to the helper, e.g.:

   • escapeForJsStringInCode(JSON.stringify(ctrl.message))

This ensures that any control characters or HTML-special characters present in ctrl.message cannot break out of string or script contexts in the final generated code, while preserving existing semantics: the runtime will still see the same string content (modulo characters that are encoded as Unicode escapes, which does not change their value once evaluated).

All changes are confined to packages/bridge-compiler/src/codegen.ts. No new external imports are needed; we can implement the escaping using built-in JavaScript string operations.

---

General approach: Introduce a small escaping helper in codegen.ts that post-processes JSON.stringify output to escape characters that could be problematic in generated code (such as <, >, /, backslashes, and certain control characters). Then, use this helper in place of bare JSON.stringify whenever a value derived from untrusted document content is interpolated into generated source strings that will be executed by AsyncFunction.

Concrete best fix here:

1. In packages/bridge-compiler/src/codegen.ts, define:

   • A CHAR_ESCAPE_MAP object mapping unsafe characters to safe escape sequences.
   • An escapeForJsStringLiteral function that takes a string (the result of JSON.stringify) and replaces any unsafe characters based on the map.

   This function should be placed near other top-level helpers, after the imports and constants, to keep it reusable.

2. Update the applyFallbacks method to wrap the three occurrences of JSON.stringify(ctrl.message) with this helper:

   • For the throw catch control:
     • In the errFlag path.
     • In the IIFE try/catch path.
   • For the panic catch control:
     • In the errFlag path.
     • In the IIFE try/catch path.

   Concretely, change JSON.stringify(ctrl.message) to escapeForJsStringLiteral(JSON.stringify(ctrl.message)) in all four places.

3. Optionally (but without changing behavior), the helper is purely string-based and does not need any new imports; use built-in String.prototype.replace and a regex literal. No other files need to change for this particular alert.

This preserves the behavior (the error/panic message is still whatever ctrl.message was) while ensuring the generated JavaScript code does not contain raw problematic characters derived from untrusted input, satisfying CodeQL’s concern and hardening the code generator.

---

General approach: Introduce a small helper that takes an arbitrary string, converts it to a JSON string literal, and then post-processes it to escape characters that could cause issues in code-generation contexts (<, >, /, backslash, control characters, Unicode line separators, etc.). Replace direct uses of JSON.stringify(ctrl.message) in generated code with this hardened helper. This preserves functionality (the message content) while hardening against code injection and satisfies CodeQL’s recommendation.

Concrete fix:

1. In packages/bridge-compiler/src/codegen.ts, define:

   • A charMap constant mapping each unsafe character to a safe escape sequence.
   • An escapeUnsafeChars function that applies these mappings to a string.
   • A safeJsonStringify helper that calls JSON.stringify and then escapeUnsafeChars on the resulting string.

2. In applyFallbacks, replace the four occurrences of JSON.stringify(ctrl.message) (lines 1987, 1989, 1993, 1995) with safeJsonStringify(ctrl.message). Since JSON.stringify returns a string (the JS literal), and escapeUnsafeChars preserves that literal semantics while just changing some characters to Unicode escapes, the generated code continues to behave the same except that problematic characters are further escaped. No other behavior of the compiler or runtime changes.

3. No imports are required; the helpers use only built-in functionality.

This single helper will address all current and future uses of unsafe JSON.stringify for messages in this file if reused elsewhere.

---

General approach: Introduce a small, central escaping helper that wraps JSON.stringify and then replaces a conservative set of “unsafe in JS/HTML context” characters (<, >, /, backslash, control characters, and the Unicode line/paragraph separators) with their \uXXXX escapes. Then replace all uses that are treated by CodeQL as “sanitization” (JSON.stringify(...) that feed into generated code) with this helper. This keeps semantics identical (they remain valid JS string literals) but ensures they are safe to embed in generated source and robust against future usage in HTML <script> contexts.

Concretely:

1. In packages/bridge-compiler/src/codegen.ts, define:

   • A charMap object mapping the unsafe characters to escaped forms.
   • A function escapeJsStringLiteral(str: string): string that:
     • Calls JSON.stringify(str) to produce a proper JS string literal.
     • Then .replacees any occurrences of the keys in charMap (including \b, \f, \n, \r, \t, \0, \u2028, \u2029, <, >, /, \\) with the mapped values.
   • A helper emitSafeStringLiteral(raw: string): string that calls escapeJsStringLiteral(raw); this is what we’ll use throughout codegen when embedding user‑controlled strings.

2. Update emitCoerced:

   • Its fallback currently does return JSON.stringify(raw);. Change this to return emitSafeStringLiteral(raw); so arbitrary string constants in the bridge doc are emitted with the strengthened escaping.

3. Update emitParsedConst:

   • Where it returns JSON.stringify(parsed); for successful parse, change to escapeJsStringLiteral(JSON.stringify(parsed)) if we are embedding a JSON string literal, or better: treat parsed as a JS value and re‑serialize safely. However, since the snippet shows return JSON.stringify(parsed);, and this is directly used in codegen, we should wrap with a dedicated helper for safely emitting the value: return safeJsonStringify(parsed); where that uses JSON.stringify then our escapeJsStringLiteral if the result is a string literal. Given the limited context, a simpler minimal change is: return escapeJsStringLiteral(JSON.stringify(parsed));.

4. Update the error‑handling helper emitParsedConst’s fallback:

   • return \JSON.parse(${JSON.stringify(raw)})`;becomesreturn `JSON.parse(${emitSafeStringLiteral(raw)})`;, so the string literal passed into JSON.parse` is safely escaped.

5. Replace all other JSON.stringify(...) occurrences that flow into generated code with the safe helper:

   • Path/property keys: change \?.[${JSON.stringify(p)}]`and${JSON.stringify(key)}to use a path/key helperemitSafePropertyKey(p)that internally callsemitSafeStringLiteral(String(p)). This ensures that when we inject porkey` into bracket notation or object literals, the inner string literal is robustly escaped.
     • Lines: 1578, 1586, 1599, 1607, 1630, 1642, 2051, 2065, 2077, 2087, 2102, 2102 (both variants), 2163, 2293, 2296, 2299, 1691, 1912, 2150.
   • Tool function names in call expressions:
     • Lines 1763 and 2160: replace JSON.stringify(fnName) with emitSafeStringLiteral(fnName).
   • Control messages used in thrown errors/panics:
     • Lines 1933, 1935, 1949, 1951, 1987, 1989, 1995: replace JSON.stringify(ctrl.message) with emitSafeStringLiteral(ctrl.message).
   • The panic error path at 1993 references CodeQL variant 1t but has the same pattern; replace there as well.

6. Any remaining JSON.stringify uses that are not contributing to generated code (e.g. for logging) can stay unchanged. Based on the snippets, all the flagged uses are in codegen expressions, so we’ll systematically migrate only those.

No changes are needed in packages/bridge/bench/compiler.bench.ts or packages/bridge-compiler/src/execute-bridge.ts; they only pass data through and do not themselves synthesize JS code from those strings.

---

General approach: Introduce a small helper that post‑processes strings produced by JSON.stringify (or other dynamic, document‑derived strings) to escape additional characters that can cause trouble in JavaScript source, such as <, >, /, backslash, null, line/paragraph separators, and ASCII control whitespace. Then replace direct uses of JSON.stringify(...) in code‑generation contexts with this safer helper. For constant coercion and const parsing helpers that return JS source, ensure they use this helper as well.

Best concrete fix: In packages/bridge-compiler/src/codegen.ts, add a charMap and escapeUnsafeChars function similar to the one in the background example, but implemented in TypeScript and tuned for use after JSON.stringify. Then:

• Change emitCoerced to return escapeUnsafeChars(JSON.stringify(raw)) in the fallback branch.
• Change emitParsedConst to wrap both JSON.stringify(parsed) and JSON.stringify(raw) with escapeUnsafeChars.
• In all locations where codegen builds property access paths or object literals with JSON.stringify(p) or JSON.stringify(key) inside template literals that form JavaScript source (e.g., ?.[${JSON.stringify(p)}], ${JSON.stringify(key)}: ...), wrap those JSON.stringify calls in escapeUnsafeChars.
• In places generating error‑throwing expressions that embed ctrl.message using JSON.stringify(ctrl.message), wrap with escapeUnsafeChars as well.
• For tool function names fnName used as string literals in generated code, wrap JSON.stringify(fnName) with escapeUnsafeChars.

This single helper will address the large set of CodeQL variants, since they all boil down to the same concern: dynamic values serialized with JSON.stringify are being embedded into generated code. No changes are needed in the benchmark files beyond using the new helper indirectly through the updated codegen support; the benchmarks’ own JSON.parse(JSON.stringify(raw)) is just cloning and is not part of code construction.

Implementation details:

• Add const unsafeCharMap and function escapeUnsafeChars(str: string): string near the other helper functions in codegen.ts (after imports or alongside emitCoerced/emitParsedConst).
• Replace each highlighted JSON.stringify(...) used in generated source with escapeUnsafeChars(JSON.stringify(...)).
• For the path building code (?.[${JSON.stringify(p)}]), we do not have to change the regular expression in escapeUnsafeChars, because JSON.stringify already ensures the content is a valid JSON string literal and we are just post‑processing the serialized form to avoid characters that might be problematic in other contexts.

No additional dependencies are required; everything can be done with standard TypeScript/JavaScript.

---

To fix the problem, we should not insert JSON.stringify(ctrl.message) directly into the generated function body. Instead, we should first escape potentially dangerous characters in the resulting JSON string so that, even if the compiled code is later embedded into an HTML context or processed in unexpected ways, characters like <, >, /, backslash, NUL, and Unicode line separators will be neutralized. This follows the pattern in the provided background example: define a character mapping and an escapeUnsafeChars helper, then wrap all JSON.stringify(...) results that flow into generated code with this helper.

Concretely in packages/bridge-compiler/src/codegen.ts, we will:

1. Add a small charMap and escapeUnsafeChars function near the top of the file (after the imports / constants) that replaces characters [<>\b\f\n\r\t\0\u2028\u2029] with safe escape sequences, and also handles / and \ similarly to the example. This helper will operate on the string result of JSON.stringify(...), not on the raw message.
2. Update all occurrences in this file where JSON.stringify of potentially untrusted data is interpolated into generated JS code to pass through escapeUnsafeChars. For this alert, that specifically includes the four uses of JSON.stringify(ctrl.message) in applyFallbacks (lines 1987, 1989, 1993, 1995). After the change, they become escapeUnsafeChars(JSON.stringify(ctrl.message)).
3. Keep all semantics the same: at runtime inside the compiled function, new Error(<string literal>) or new __BridgePanicError(<string literal>) will receive the exact same logical string value, because the additional escaping affects only the source text; the JavaScript engine will interpret \u003C as <, etc. So behavior is preserved while the generated code is safer to embed and satisfies CodeQL’s requirements.

No changes are required in packages/bridge/bench/compiler.bench.ts or packages/bridge-compiler/src/execute-bridge.ts for this specific sink; they are just part of the taint flow path. The only new code we introduce is the small helper and its usage, with no external dependencies.

General approach: Introduce a central escaping helper for “untrusted string becoming part of generated JavaScript source”, and use it instead of raw JSON.stringify wherever tainted values are interpolated into generated code. This helper should (a) JSON-encode the value (so it’s a valid JS string literal), and then (b) post-process the resulting literal to replace characters that can affect HTML script parsing or line structure (<, >, /, \, control chars, \u2028, \u2029) with safe escape sequences.

Best concrete fix while preserving functionality:

1. In packages/bridge-compiler/src/codegen.ts, define a charMap and escapeUnsafeChars similar to the background example, plus a convenience wrapper jsStringLiteral(raw: string): string that does escapeUnsafeChars(JSON.stringify(raw)). Also define wrappers for values we pass through JSON.stringify that are already JSON (emitParsedConst) or error messages / keys.
2. Replace direct uses of JSON.stringify for tainted values with the safe helper:
   • In emitCoerced, change the fallback from JSON.stringify(raw) to jsStringLiteral(raw).
   • In emitParsedConst, when JSON.parse fails, change JSON.parse(${JSON.stringify(raw)}) to use jsStringLiteral(raw), and when returning JSON.stringify(parsed), wrap it with escapeUnsafeChars (since that string is spliced into code).
3. For all occurrences flagged in the variants where we embed path segments, keys, function names, or messages into template literals that contribute to functionBody, replace JSON.stringify(...) with jsStringLiteral(...). These include:
   • Path accesses: every ?.[${JSON.stringify(p)}] and [\${JSON.stringify(p)}].
   • Object literal keys we emit (e.g. ${JSON.stringify(key)}: ...).
   • Tool names in tools[${JSON.stringify(fnName)}] and the third argument to __call.
   • Error and panic messages wrapped in new Error(...) and new __BridgePanicError(...).
   • The JSON.stringify(ref) in the thrown “Unknown reference” error.
4. This maintains the logical behavior (same values, same control flow) but ensures the generated JS is robust even if bridge consts, keys, messages, or paths contain problematic characters. We don’t change any imports or external APIs; everything is local helpers.

packages/bridge/bench/compiler.bench.ts doesn’t need modification: its JSON.parse(JSON.stringify(raw)) is just for cloning and doesn’t participate directly in string-based code generation; the problematic sink is in codegen.ts.

---

General approach: Introduce a small, well-scoped escaping helper that takes a string already serialized with JSON.stringify and replaces characters that can break out of JavaScript string/HTML/script contexts (<, >, /, backslash, control characters, Unicode line/paragraph separators) with safe escape sequences. Then, use this helper consistently for all values that come from the document or user-controlled sources when embedding them into the generated function body, instead of using bare JSON.stringify(...) inside template literals.

Concrete fix:

1. In packages/bridge-compiler/src/codegen.ts, define a charMap and an escapeUnsafeChars function, closely following the pattern from the example, and a convenience wrapper jsStringLiteral that both JSON.stringifys a value and runs it through escapeUnsafeChars. This keeps behavior (values, quoting) the same but adds safety.

2. Replace all uses of JSON.stringify(...) that feed into generated code with jsStringLiteral(...) (or escapeUnsafeChars(JSON.stringify(...)) if the value is already a stringified JSON value), for:

   • emitCoerced fallback (JSON.stringify(raw)),
   • emitParsedConst’s JSON.stringify(parsed) and the JSON.parse(${JSON.stringify(raw)}) case,
   • All path/key insertions like `?.[${JSON.stringify(p)}]` and object entries ${JSON.stringify(key)}: ...,
   • Tool name insertions such as tools[${JSON.stringify(fnName)}] and the tool-name log argument ${JSON.stringify(fnName)},
   • Error/panic control messages using JSON.stringify(ctrl.message),
   • The “unknown reference” error string JSON.stringify(ref).

3. The specific sink noted in the main alert — preamble on line 1276 — is a concatenation of lines previously pushed into preambleLines. Those lines include code built with the vulnerable JSON.stringify calls (keys, paths, fnName, ctrl.message) inside collectElementPreamble and its helpers. By changing all those JSON.stringify uses to the new escaping helper, preamble becomes safe as well, and all 37 alert variants are addressed.

No other files need modification. No external dependencies are required; the escaping helper can be implemented directly in codegen.ts.

---

In general terms, when constructing JavaScript source code from dynamic values, ensure that any untrusted strings embedded into that source are escaped so they cannot break the surrounding syntax or inject additional code. For values used as property keys, we can still use JSON.stringify to get a valid JavaScript string literal, but we should additionally escape characters that may cause problems when this literal is ultimately embedded in a <script> block or otherwise treated as HTML/JS text.

The most targeted fix here is to wrap every JSON.stringify(key) used in serializeOutputTree with an escaping helper that replaces potentially dangerous characters (<, >, /, backslash, control characters, and Unicode line separators) with their safe escape sequences, similar to the example in the background. This keeps the semantics of property names intact—because they are still valid JS string literals—but ensures the resulting generated function body does not contain raw problematic characters derived from untrusted input. Concretely, in packages/bridge-compiler/src/codegen.ts we will: (1) add a small escapeUnsafeChars helper (and its charMap) in this file; (2) change the three occurrences of JSON.stringify(key) inside serializeOutputTree (lines 1306, 1309, 1313) to escapeUnsafeChars(JSON.stringify(key)). No imports are needed, and this change is fully local to the shown file.

General fix approach: Wrap JSON.stringify(key) with an additional escaping function that replaces characters dangerous in JavaScript/HTML contexts (<, >, /, backslash, certain control chars and Unicode line separators) with safe escape sequences (e.g., \u003C). This preserves the semantic meaning of the string while preventing it from prematurely terminating <script> blocks or altering the generated code structure.

Concrete best fix here: Define a small charMap and escapeUnsafeChars helper in codegen.ts, near where the other codegen utilities live, and then update serializeOutputTree to call escapeUnsafeChars(JSON.stringify(key)) whenever serializing object keys into generated JS. Specifically:

• Add at top-level in packages/bridge-compiler/src/codegen.ts (after existing constants or before methods) a const charMap and function escapeUnsafeChars(str: string): string that:
  • Uses a regular expression to find characters [<>\b\f\n\r\t\0\u2028\u2029] and replaces them using the mapped escape codes; include mappings for backslash and / as well.
• In serializeOutputTree (lines ~1295–1320):
  • Replace each occurrence of ${JSON.stringify(key)} with ${escapeUnsafeChars(JSON.stringify(key))}.
  • This affects three lines: 1306, 1309, and 1313, covering all CodeQL references.

No behavior changes occur for typical safe keys; they just gain extra escaping where necessary. No external dependencies are needed; we can implement this with built-in string/regex behavior.

---

General approach: Whenever we interpolate user‑controlled strings into generated JavaScript source, we must ensure those strings are rendered as safe string literals. JSON.stringify ensures proper JS string literal syntax but does not escape <, >, /, and certain Unicode separators that static analysis treats as unsafe. We should implement a small helper that post‑processes JSON.stringify output to escape these characters and then use this helper everywhere we currently interpolate JSON.stringify(ctrl.message) (and any similar uses we can see in the snippet) into the generated code.

Best concrete fix:

1. In packages/bridge-compiler/src/codegen.ts, add a charMap and escapeUnsafeChars helper near the top (after imports / constants is fine).
2. Replace the two instances in applyFallbacks where JSON.stringify(ctrl.message) is directly concatenated into expr with escapeUnsafeChars(JSON.stringify(ctrl.message)).
3. Review other uses of JSON.stringify that feed into code generation in this file. From the snippet, the other occurrences (e.g., JSON.stringify(tw.target), JSON.stringify(bKey), JSON.stringify(fnName), JSON.stringify(p) in optional chaining) are stringified keys and function names that originate from the Bridge document and tool definitions. For consistency and to cover all 3 alert variants, we should also wrap these with escapeUnsafeChars(...) since they are used to build code strings executed by AsyncFunction.

No changes are required in execute-bridge.ts or the benchmark files: the benchmarks only demonstrate tainted data flow; the sink that needs hardening is in codegen.ts.

Concretely:

• Add the helper in codegen.ts (e.g., around the top after const SELF_MODULE = "_").
• Update:
  • line 1959: JSON.stringify(ctrl.message) → escapeUnsafeChars(JSON.stringify(ctrl.message))
  • line 1961: likewise.
• Update other code‑string construction sites that use JSON.stringify:
  • line 2141: key for constant tool wire target.
  • line 2150: key for pull tool wire target.
  • line 2160: key for bridge wire key.
  • line 2170: two uses of JSON.stringify(fnName).
  • line 2173: JSON.stringify(p) inside the optional chaining path.

No new external packages are necessary; this can be done with a small local helper.

---

In general, any time untrusted or semi-trusted strings are interpolated into generated JavaScript source, even when wrapped via JSON.stringify, we should perform an additional escaping pass that replaces characters like <, >, /, backslashes, control characters, and Unicode line separators with their safe escape sequences. This prevents breaking out of <script> tags and avoids edge cases where host environments treat certain sequences specially.

The concrete fix here is to introduce a small helper in packages/bridge-compiler/src/codegen.ts (close to the top-level helpers) that performs this post-processing, using the same charMap/escapeUnsafeChars pattern as in the background example, but adapted to operate on the already-stringified JSON. Then we replace all direct interpolations of JSON.stringify(...) that are part of the generated JavaScript source with escapeUnsafeChars(JSON.stringify(...)). This includes: the nullishControl branches that throw Error or __BridgePanicError (lines 1959–1961), and the places that embed tool names, targets, and keys into generated code: building tool input objects (JSON.stringify(tw.target), JSON.stringify(bKey)), and emitting the tool call tools[${JSON.stringify(fnName)}] and optional chaining paths ?.[${JSON.stringify(p)}]. Those values can be influenced by the Bridge document and therefore ultimately by untrusted bridgeText.

Specifically:

• In codegen.ts, add const charMap = { ... } and function escapeUnsafeChars(str: string): string { ... } near the other top-level helpers.
• Update the applyFallbacks method:
  • Change JSON.stringify(ctrl.message) in both throw and panic branches to escapeUnsafeChars(JSON.stringify(ctrl.message)).
• Update the tool invocation code near the bottom:
  • For object literal property keys, change JSON.stringify(tw.target) and JSON.stringify(bKey) to escapeUnsafeChars(JSON.stringify(tw.target)) and escapeUnsafeChars(JSON.stringify(bKey)).
  • For the function name and property paths, change JSON.stringify(fnName) and JSON.stringify(p) similarly.
    No new imports are needed; the helper uses only core language features. Functionality remains the same except that certain characters in messages and identifiers are encoded as \uXXXX, which is harmless for error messages and property accesses but prevents problematic raw characters from appearing in the generated source.

General approach: Introduce a small helper in codegen.ts that takes a string, runs JSON.stringify, and then additionally escapes characters problematic in <script> contexts (<, >, /, certain Unicode line separators, etc.), and another helper that takes arbitrary values and returns a safe JS string literal. Then replace all direct uses of JSON.stringify(...) that feed into generated code (property names, string literals, function names, messages, paths) with these helpers. This preserves existing runtime semantics (still valid JS, same values when evaluated) but satisfies CodeQL by ensuring no unsafe characters appear raw inside the generated JS source.

Concretely:

1. In packages/bridge-compiler/src/codegen.ts, add:

   • A charMap and escapeUnsafeCharsInJsonLiteral(json: string): string that assumes its input is already a JSON string literal (including quotes) and replaces dangerous characters inside it.
   • A toSafeJsonStringLiteral(value: string): string that calls JSON.stringify(value) and then escapeUnsafeCharsInJsonLiteral.
   • A toSafeJsonPropertyKey(value: string): string for property keys used in bracket notation (essentially same as toSafeJsonStringLiteral).

2. Update emitCoerced:

   • For the fallback case, instead of return JSON.stringify(raw);, call toSafeJsonStringLiteral(raw). Other cases (booleans, numbers, already‑quoted string literals) stay as is.

3. Update emitParsedConst:

   • Change return JSON.stringify(parsed); to return escapeUnsafeCharsInJsonLiteral(JSON.stringify(parsed));.
   • Change the fallback return JSON.parse(${JSON.stringify(raw)}); to use the safe literal: JSON.parse(${toSafeJsonStringLiteral(raw)}).

4. Replace other generated‑code JSON.stringify uses with the helper:

   • Path segments and keys embedded as ?.[${JSON.stringify(p)}] or ${JSON.stringify(key)} in wireToExpr, elementWireToExpr, refToExpr, lazyRefToExpr, buildInlineToolExpr, buildElementToolInput, and serializeTreeNode → use toSafeJsonPropertyKey(...).
   • Tool function names and bridge function names used as tools[${JSON.stringify(fnName)}] or passed as arguments in generated call strings → use toSafeJsonPropertyKey(fnName) (still a string literal).
   • Error/panic/throw control messages JSON.stringify(ctrl.message) in applyFallbacks and subsequent control‑flow sections → use toSafeJsonStringLiteral(ctrl.message).

5. No change is required for line 1988 in terms of data; we just ensure that any expr components that come from JSON stringification are now safely escaped. The expression throw ${errFlag} itself uses an identifier, not user data.

The benchmark helper files (compiler.bench.ts, engine.bench.ts) use JSON.stringify only to deep‑clone parsed documents and do not participate in code generation; CodeQL taints them as sources but there is no need to alter their behavior. Since we are only allowed to modify the specified files and the security improvement is centered in codegen.ts, we will not touch the bench files.

No new external dependencies are needed; we implement escaping inline.

---

In general, to fix this class of issues you should ensure that any untrusted data that ends up in generated JavaScript code is passed through a sanitizer that escapes characters with special semantics in JavaScript and in typical embedding contexts (such as <, >, /, backslash, and certain control characters), in addition to the basic escaping done by JSON.stringify. The pattern is: safeLiteral = escapeUnsafeChars(JSON.stringify(untrustedValue)), and then interpolate safeLiteral into your template literal.

Concretely for this codebase, we should:

1. Add an escapeUnsafeChars helper in packages/bridge-compiler/src/codegen.ts, close to the top-level helpers, that:
   • Defines a charMap for problematic characters.
   • Applies a .replace over a regular expression matching those characters.
2. Replace every occurrence of JSON.stringify(ctrl.message) in applyFallbacks with escapeUnsafeChars(JSON.stringify(ctrl.message)), covering:
   • The throw control branch with and without errFlag (lines ~1997 and ~1999).
   • The panic control branch with and without errFlag (lines ~2003 and ~2005).
3. No changes are required in the benchmark files themselves (compiler.bench.ts, engine.bench.ts); they are only the sources used in the CodeQL trace, not the sinks.
4. No new imports are needed; we can implement escapeUnsafeChars using standard JavaScript features within codegen.ts.

This preserves all existing behavior except that certain characters in ctrl.message are now emitted as Unicode escapes in the generated code, which is semantically equivalent for the resulting runtime string but safer for code generation and satisfies CodeQL’s expectation for additional sanitization.

---