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_DENIED toolResult lines in the accessible session transcript slice.
• Rankings below separate observed facts from inferred routing/volume.

---

Exec denials

Directly observed

1. 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?”

1. The current requester session shows repeated ad hoc exec usage with inline Python heredocs while the agent was doing ordinary parsing/search work. Those are the exact command shapes that hit OpenClaw’s strictInlineEval gate.

1. The OpenClaw runtime code confirms the deny path:

• dist/node-cli-BiVwcI0i.js:1174-1208
• Behavior: when strictInlineEval is enabled and an inline interpreter pattern is detected, OpenClaw emits:
• SYSTEM_RUN_DENIED: approval required (... requires explicit approval in strictInlineEval mode)

1. The requester session also shows multiple ordinary shell commands succeeding, including grep, find, cat|sed|grep, and git, with no corresponding false-positive deny evidence in the transcript slice I could access.

1. The local config probe in the requester session returned missing paths for:

• tools.exec
• browser
• browser.profiles.user
• browser.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_DENIED events 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

1. Pete reported 15 remote-debugging approval prompts at 2026-04-23 14:29:48 PDT.

1. Browser docs explain exactly why this happens for the user profile:

• browser.md:389-463
• user is an existing-session Chrome MCP attach flow.
• Required steps:

1. open browser inspect page for remote debugging
2. enable remote debugging
3. keep browser running
4. approve the attach prompt when OpenClaw connects

1. 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.

1. Browser-login docs say the recommended login path is the host openclaw profile, not the signed-in user profile, for sites like X/Twitter:

• browser-login.md:8-38
• browser-login.md:30-36

1. The requester session’s config probe showed browser.defaultProfile => <missing>, and docs say default browser profile is openclaw unless explicitly changed.

• browser.md:198
• openclaw.json has 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.json does not set browser.defaultProfile to user, these prompts are not coming from normal default browser usage. They come from explicit profile="user" routing.

---

User-profile workflow audit

Observed and configured routes to profile="user"

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-briefing currently routes to user
• OpenClaw’s browser-login docs recommend the host openclaw profile 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 of read, edit, or a checked-in helper script

What I did not find

1. I did not find evidence that openclaw.json is forcing this behavior.
2. I did not find evidence that the audited skills are shipping giant heredoc templates as part of their written instructions.
3. Workspace guidance says “use python3, not python”, but it does not require heredoc style.

Root-cause call

Best evidence-backed root cause split:

• Primary cause: main-agent and subagent direct exec habits 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.

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

---

Smallest changes short of config edits

These are the smallest changes that reduce pain without touching gateway config.

1. 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.

1. Move X/Twitter workflows off profile="user" unless there is a hard reason not to.

• daily-twitter-briefing is the clearest candidate.
• Browser-login docs already point to the better path: host openclaw profile, manual login.

1. Keep profile="user" only on LinkedIn workflows that truly need Pete’s live logged-in state.

• linkedin-invites: yes
• personal-one-pager: only for LinkedIn phases

1. 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.

1. 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.md
• existing-session / user attach 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 openclaw manual-login flow for X/Twitter: lines 8-38
• /opt/homebrew/lib/node_modules/openclaw/dist/node-cli-BiVwcI0i.js
• strictInlineEval gate 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 user existing-session profile

Local config

• /Users/vinny/.openclaw/openclaw.json
• no explicit tools.exec or browser override found in the audited readback

---

Final diagnosis

If Pete wants data before touching guardrails, the data says this:

1. 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.

1. 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.

1. 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.