OpenClaw gateway denial and user-profile browser audit
Date: 2026-04-23 Time zone: America/Los_Angeles
Scope and evidence model
This audit is read-only, except for this artifact.
Primary evidence sources used:
- Session transcript:
/Users/vinny/.openclaw/agents/main/sessions/0cc94e0e-3fd2-4435-b938-56ead22f400c.jsonl - Skills:
/Users/vinny/.openclaw/workspace/skills/daily-twitter-briefing/SKILL.md/Users/vinny/.openclaw/workspace/skills/linkedin-invites/SKILL.md/Users/vinny/.openclaw/workspace/skills/personal-one-pager/SKILL.md- Browser docs:
/opt/homebrew/lib/node_modules/openclaw/docs/tools/browser.md/opt/homebrew/lib/node_modules/openclaw/docs/tools/browser-login.md- Gateway/config docs:
/opt/homebrew/lib/node_modules/openclaw/docs/gateway/configuration-reference.md- Runtime code:
/opt/homebrew/lib/node_modules/openclaw/dist/node-cli-BiVwcI0i.js- Local config:
/Users/vinny/.openclaw/openclaw.json
Limits:
- I did not verify a standalone gateway log file path from shell search in this subagent session.
- I did not find literal
SYSTEM_RUN_DENIEDtoolResult lines in the accessible session transcript slice. - Rankings below separate observed facts from inferred routing/volume.
Exec denials
Directly observed
- Pete reported a burst of browser prompts and gateway-denied concern at 2026-04-23 14:29:48 PDT in the requester session:
- Source:
0cc94e0e-3fd2-4435-b938-56ead22f400c.jsonl - Quote: “I had to click allow remote de bugging 15 times... This Gateway denied issue is that separate and again?”
- The current requester session shows repeated ad hoc
execusage with inline Python heredocs while the agent was doing ordinary parsing/search work. Those are the exact command shapes that hit OpenClaw’sstrictInlineEvalgate.
- The OpenClaw runtime code confirms the deny path:
dist/node-cli-BiVwcI0i.js:1174-1208- Behavior: when
strictInlineEvalis enabled and an inline interpreter pattern is detected, OpenClaw emits: SYSTEM_RUN_DENIED: approval required (... requires explicit approval in strictInlineEval mode)
- The requester session also shows multiple ordinary shell commands succeeding, including
grep,find,cat|sed|grep, andgit, with no corresponding false-positive deny evidence in the transcript slice I could access.
- The local config probe in the requester session returned missing paths for:
tools.execbrowserbrowser.profiles.userbrowser.defaultProfile
This means there is no local override in openclaw.json for these settings. Defaults are in effect.
Diagnosis
Best evidence-backed answer to Pete’s question:
- In the accessible evidence, the denial mechanism lines up with inline interpreter eval, not ordinary commands.
- I found no direct evidence of false positives on normal grep/find/git commands.
- I found multiple direct examples of inline Python heredocs, including during mundane file-inspection tasks where
read,edit, or a checked-in helper script would have been enough.
Counts
Observed in the accessible requester-session evidence:
- Literal
SYSTEM_RUN_DENIEDevents in transcript: 0 observed - User-reported current denial concern: 1 reported burst, same message as the 15 browser prompts
- Inline Python heredoc exec calls: at least 4 observed across Apr 22 to Apr 23, 3 of them directly visible in the requester-session slice I inspected
- Ordinary non-inline shell commands observed succeeding: at least 9
Bottom line: the evidence points much more strongly to heredoc / inline-eval shaped commands than to false positives on normal commands.
Browser user-profile prompts
Directly observed
- Pete reported 15 remote-debugging approval prompts at 2026-04-23 14:29:48 PDT.
- Browser docs explain exactly why this happens for the
userprofile:
browser.md:389-463useris anexisting-sessionChrome MCP attach flow.- Required steps:
- open browser inspect page for remote debugging
- enable remote debugging
- keep browser running
- approve the attach prompt when OpenClaw connects
- Browser docs explicitly limit when
profile="user"should be used:
browser.md:467-474- Use it only when the user’s logged-in state matters, and only when the user is present to approve the attach prompt.
- Browser-login docs say the recommended login path is the host
openclawprofile, not the signed-inuserprofile, for sites like X/Twitter:
browser-login.md:8-38browser-login.md:30-36
- The requester session’s config probe showed
browser.defaultProfile => <missing>, and docs say default browser profile isopenclawunless explicitly changed.
browser.md:198openclaw.jsonhas no browser override
Historical observed browser incident
From the requester session’s memory-search result:
- 2026-04-16 16:00:55 PDT
- “The 4pm Twitter briefing failed because the browser tool timed out before I could reach Pete’s signed-in X session.”
- Source surfaced by memory in requester session, path:
artifacts/vinny-discord-server-export-last-21-days.md:19663-19666
Diagnosis
Best evidence-backed answer:
- The repeated prompt issue is separate from gateway exec denial mechanics.
- It is tied to workflows that still route through
profile="user", which uses a live attach flow and requires consent prompts. - Because
openclaw.jsondoes not setbrowser.defaultProfiletouser, these prompts are not coming from normal default browser usage. They come from explicitprofile="user"routing.
User-profile workflow audit
Observed and configured routes to profile="user"
| Rank | Workflow | Evidence | Prompt-volume basis | Genuine live session needed? | Verdict |
|---|---|---|---|---|---|
| 1 | daily-twitter-briefing | Skill hard-codes profile="user"; 3 cron runs/day; historical failure on signed-in X session at 2026-04-16 16:00:55 PDT | Highest, 3 scheduled attaches/day before any manual use | No, not in current form. Docs recommend host openclaw browser with manual login for X/Twitter | Lazy routing, top suspect |
| 2 | linkedin-invites | Skill explicitly says use profile="user" and signed-in LinkedIn session | High per run, many browser actions inside one workflow | Yes, invitation manager and LinkedIn acceptance flows need logged-in state | Legitimate user route |
| 3 | personal-one-pager | Skill explicitly says use profile="user" and signed-in LinkedIn session for profile/posts | Medium per run | Partially. LinkedIn phase yes, broader web research no | Mostly legitimate, but only LinkedIn substeps need it |
| 4 | linkedin-invites VIP handoff to personal-one-pager | linkedin-invites calls personal-one-pager for VIPs | Medium multiplier on top of invites flow | Same as above | Legitimate, but multiplies attach pressure |
| 5 | No fifth explicit hard-routed user workflow found in audited skills/config | Skill audit + config audit | 0 | N/A | Default browser routing is not the culprit |
Key finding
The top browser-routing problem is not the default browser profile. It is the set of workflows that explicitly choose profile="user".
The clearest routing bug is:
daily-twitter-briefingcurrently routes touser- OpenClaw’s browser-login docs recommend the host
openclawprofile for X/Twitter manual login - Therefore this workflow is the strongest candidate for prompt spam that is avoidable without any gateway config change
Inline-Python root cause
What I found
The giant inline Python / heredoc pattern is leaking in mainly through direct agent exec habits, not through checked-in scripts.
Direct evidence from the requester session:
- inline Python used to inspect config
- inline Python used to scrape doc matches into an artifact
- inline Python used in earlier ordinary data-extraction work
- ordinary file parsing/search steps often chose
exec + python3 - <<'PY'instead ofread,edit, or a checked-in helper script
What I did not find
- I did not find evidence that
openclaw.jsonis forcing this behavior. - I did not find evidence that the audited skills are shipping giant heredoc templates as part of their written instructions.
- Workspace guidance says “use
python3, notpython”, but it does not require heredoc style.
Root-cause call
Best evidence-backed root cause split:
- Primary cause: main-agent and subagent direct
exechabits for quick parsing and search tasks - Secondary cause: no small checked-in helper utilities for repeated local parsing tasks, so the agent improvises with heredocs
- Not the main cause: existing scripts or skill templates, based on the files I audited
Top 5 denial patterns
This table ranks observed command shapes in the accessible evidence, then marks whether each shape actually overlaps the strictInlineEval deny path.
| Rank | Pattern | Count observed | Denial correlation | Representative example | Smallest non-config change | ||
|---|---|---|---|---|---|---|---|
| 1 | python3 - <<'PY' / python3 <<'PY' inline heredoc | 4 | Direct. This is the exact shape strictInlineEval is designed to stop | 2026-04-23 14:50:31 PDT, doc-match extraction via inline Python | Replace with read / edit / write when local file access is enough, or a checked-in helper script like workspace/scripts/extract_doc_matches.py | ||
| 2 | Recursive grep search | 4 | None observed | 2026-04-23 14:50:07 PDT, grep -Rni "strictInlineEval" ... succeeded | Prefer read on known files, or one reusable checked-in search helper instead of ad hoc grep chains | ||
| 3 | `find ... | sed/head` file discovery pipelines | 2 | None observed | 2026-04-23 14:47 PDT, doc-file discovery pipelines succeeded | Use deterministic known paths from docs/config, or a tiny checked-in locator script | |
| 4 | `cat | sed | grep` transcript introspection pipelines | 2 | None observed | 2026-04-23 14:50 PDT, session transcript grep succeeded | Use read with offsets on the transcript file instead of shell pipelines |
| 5 | Background grep plus process poll follow-up | 1 | None observed | 2026-04-23 14:49:46 PDT to 14:50:07 PDT, grep launched then polled | Run a direct read on the target file, or use one foreground helper that writes a stable artifact |
What this means
The only pattern in the top 5 that maps directly to the gateway deny path is inline Python heredoc. The rest are ordinary shell commands and, in the accessible evidence, they succeeded.
So the answer to “mostly heredoc/inline-eval shaped vs false positives on normal commands?” is:
- Mostly heredoc / inline-eval shaped
- No direct false-positive pattern on normal commands found in the evidence I could access
Top 5 user-profile workflows
| Rank | Workflow | Evidence | Prompt volume | Needs live session? | Smallest non-config change |
|---|---|---|---|---|---|
| 1 | daily-twitter-briefing | hard-coded profile="user"; 3 cron windows/day; historical signed-in X timeout | Highest | No, current docs prefer host openclaw profile | Change skill routing to host openclaw browser, manual login retained |
| 2 | linkedin-invites | hard-coded profile="user" | High | Yes | Keep user, but ensure one attach per run, not repeated reconnects |
| 3 | personal-one-pager | hard-coded profile="user" for LinkedIn profile/posts | Medium | Partially | Restrict user to the LinkedIn phase only, do web search outside it |
| 4 | VIP deep-dive path from linkedin-invites to personal-one-pager | explicit delegation in skill | Medium multiplier | Partially | Reuse one attached session where possible, avoid re-attaching for every VIP |
| 5 | No fifth explicit route found | skill/config audit | 0 | N/A | Treat default openclaw browser as the safe baseline |
Smallest changes short of config edits
These are the smallest changes that reduce pain without touching gateway config.
- Stop using inline Python heredocs for routine local-file work.
- Prefer
read,edit,write. - If shell processing is still needed, add tiny checked-in helper scripts and invoke them by file path.
- Move X/Twitter workflows off
profile="user"unless there is a hard reason not to.
daily-twitter-briefingis the clearest candidate.- Browser-login docs already point to the better path: host
openclawprofile, manual login.
- Keep
profile="user"only on LinkedIn workflows that truly need Pete’s live logged-in state.
linkedin-invites: yespersonal-one-pager: only for LinkedIn phases
- Avoid repeated attach cycles inside one workflow.
- If a skill uses
profile="user", structure it so it attaches once and reuses that session. - The 15-prompt complaint strongly suggests repeated attach attempts, not one stable attach.
- Replace ad hoc search pipelines with deterministic helper utilities.
- This reduces both gateway security friction and prompt-token bloat.
Evidence paths
Session and transcript evidence
/Users/vinny/.openclaw/agents/main/sessions/0cc94e0e-3fd2-4435-b938-56ead22f400c.jsonl- user complaint about 15 prompts and gateway-denied concern: around transcript line 319
- memory result with 2026-04-16 signed-in X timeout: around transcript line 321
- config probe showing missing browser/tools.exec overrides: around transcript line 324
- strictInlineEval grep result: around transcript line 327
- inline Python doc-match helper: around transcript lines 329-331
Skills
/Users/vinny/.openclaw/workspace/skills/daily-twitter-briefing/SKILL.md/Users/vinny/.openclaw/workspace/skills/linkedin-invites/SKILL.md/Users/vinny/.openclaw/workspace/skills/personal-one-pager/SKILL.md
Docs and runtime code
/opt/homebrew/lib/node_modules/openclaw/docs/tools/browser.mdexisting-session/userattach flow: lines 389-463- when to use
profile="user": lines 467-474 /opt/homebrew/lib/node_modules/openclaw/docs/tools/browser-login.md- recommended host
openclawmanual-login flow for X/Twitter: lines 8-38 /opt/homebrew/lib/node_modules/openclaw/dist/node-cli-BiVwcI0i.jsstrictInlineEvalgate and deny message: lines 1174-1208/opt/homebrew/lib/node_modules/openclaw/docs/gateway/configuration-reference.md- all config fields optional, safe defaults when omitted
- browser profile examples, including
userexisting-session profile
Local config
/Users/vinny/.openclaw/openclaw.json- no explicit
tools.execor browser override found in the audited readback
Final diagnosis
If Pete wants data before touching guardrails, the data says this:
- Exec-denial risk is concentrated in inline interpreter eval, especially Python heredocs.
I found repeated examples of that pattern and no matching evidence of normal-command false positives.
- Browser prompt pain is concentrated in explicit
profile="user"routes, not the default browser path.
The biggest routing bug is daily-twitter-briefing, because current docs recommend host openclaw login for X/Twitter instead.
- The heredoc leak is mostly agent habit, not repository architecture.
The right first fix is routing and helper-script discipline, not config tuning on a guess.