OpenClaw Fences External Hook Job Names and Stops Codex Relays from Running for Unmatched Tools
Two merged fixes tighten the external-hook boundary: untrusted job names stay inside fenced content, while Codex relay work now follows explicit tool matchers.
OpenClaw has merged two fixes at the external-hook and Codex tool boundary. One is a prompt-injection correction: an external hook could control a cron job name that OpenClaw placed on a trusted Task: line above the external-content fence for an isolated agent. The other is an execution-scope correction: once any relevant hook, trusted-tool policy or result middleware existed, Codex app-server tool calls could spawn openclaw hooks relay even for tools that did not match the registration.
The fixes move untrusted metadata inside the untrusted region and make relay activation follow explicit tool matchers. Operators accepting externally supplied hook jobs or running Codex with tool hooks should treat a containing build as a security and availability upgrade.
The operator decision
| Exposure | Response |
|---|---|
| External systems can create or name hook-triggered jobs | Prioritize the prompt-boundary fix and restrict accepted metadata until a containing build is deployed |
| Codex runs with tool hooks, trusted-tool policy or result middleware | Audit matchers and watch relay process fan-out, especially on constrained hosts |
| Hook inputs are fully local and Codex relay integrations are unused | Lower urgency, but include both boundaries in the next upgrade review |
| Building from source | Pin a commit containing PRs #112501 and #109603; do not rely on a moving main |
| Installing packages | Confirm inclusion from release evidence; a merged PR is not proof your installed build is fixed |
A job name crossed the trust fence
The supplied upstream record for PR #112501 describes the vulnerable construction: buildSafeExternalPrompt() put an externally supplied cron job name on an OpenClaw-authored Task: line above the external-content fence. A crafted name could include forged fence markers or model-special-token text, making attacker-controlled content appear to occupy the trusted prompt region.
The important point is not whether a particular model follows the injected text. The structural guarantee was false: content labelled as trusted was not entirely controlled by OpenClaw. The merged fix fences the external job name with the rest of the external material.
This is a prompt-boundary flaw, not evidence that arbitrary code execution occurred. Actual impact depends on the tools, approvals, sandbox, model and downstream policy available to the isolated run. Operators should still assume hostile metadata will eventually be interpreted adversarially and enforce authority outside the prompt.
Tool matchers must control relay work
PR #109603 fixes a separate but related scope failure in the Codex app-server path. Registering one tool hook, trusted-tool policy or result middleware could cause relay processes to be spawned for every tool call, even when the registration applied only to one tool.
On constrained hosts, unnecessary relay fan-out can consume process and memory capacity. More importantly, policy machinery should not be invoked outside its declared matcher scope. The upstream commit record says the final work rejects sparse matchers, fails closed on invalid policy matchers and tests composed scopes.
Interpretation: a tool matcher is part of the security boundary, not a performance hint. “No match” should mean no relay activation, while malformed policy should not broaden execution by accident.
Immediate containment before upgrade
If a containing build is not yet available:
- do not allow arbitrary external parties to choose hook job names;
- normalize length and character set at the ingress boundary, while recognizing that filtering is only containment—not the structural fix;
- keep isolated-agent tool authority minimal and retain approval gates for consequential actions;
- review hook and policy matchers for explicit tool identities;
- monitor relay child-process counts and abort runs that exhibit unexplained fan-out; and
- avoid logging full external payloads or secret-bearing tool arguments during investigation.
Do not attempt to validate the issue with real secrets, production tools or model-special-token payloads against a live agent.
Safe acceptance test
Use a disposable agent with harmless tools:
- Submit an external job whose name contains benign text resembling prompt delimiters.
- Capture the rendered prompt through an approved test fixture and confirm all external metadata remains inside the external-content boundary.
- Verify the model receives no consequential tool authority in this test.
- Register a hook that matches exactly one harmless tool.
- Invoke one matching and several non-matching tools through Codex.
- Confirm relay activation occurs only for the matching tool.
- Test malformed and incomplete matcher fixtures; expect rejection or fail-closed behaviour, never match-all expansion.
- Cancel a run and confirm hook/relay children terminate without leaking processes.
Prompt snapshots and process counts are useful evidence. Model compliance alone is not: a model ignoring one payload does not prove the boundary is safe.
Evidence and limits
OpenClaw Academy reviewed official merged PR and commit records from the repository collector. The prompt-boundary record is source ID 23392; its paired commit is 23192. The Codex relay work is represented by PR ID 23372, commit ID 23172 and documentation-change ID 23267. Live source retrieval was unavailable during this run, so the prompt-boundary source list links to the exact PR rather than inventing a commit URL from an unavailable full hash.
We did not send adversarial metadata to a live model or measure relay fan-out on a constrained host. Upstream implementation and test claims remain attributed. No supplied release record identifies a packaged containing version.
Bottom line
Untrusted metadata belongs inside the untrusted fence, and unmatched tools should not activate policy relays. Restrict external job naming and Codex hook scope now, then verify both invariants with harmless fixtures when a confirmed containing build is available.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF