other

OpenClaw gateway denial and user-profile browser audit

2026-04-23

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:

Limits:


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:
  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:
  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:

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:

Counts

Observed in the accessible requester-session evidence:

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:
  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:
  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:
  1. The requester session’s config probe showed browser.defaultProfile => <missing>, and docs say default browser profile is openclaw unless explicitly changed.

Historical observed browser incident

From the requester session’s memory-search result:

Diagnosis

Best evidence-backed answer:


User-profile workflow audit

Observed and configured routes to profile="user"

RankWorkflowEvidencePrompt-volume basisGenuine live session needed?Verdict
1daily-twitter-briefingSkill hard-codes profile="user"; 3 cron runs/day; historical failure on signed-in X session at 2026-04-16 16:00:55 PDTHighest, 3 scheduled attaches/day before any manual useNo, not in current form. Docs recommend host openclaw browser with manual login for X/TwitterLazy routing, top suspect
2linkedin-invitesSkill explicitly says use profile="user" and signed-in LinkedIn sessionHigh per run, many browser actions inside one workflowYes, invitation manager and LinkedIn acceptance flows need logged-in stateLegitimate user route
3personal-one-pagerSkill explicitly says use profile="user" and signed-in LinkedIn session for profile/postsMedium per runPartially. LinkedIn phase yes, broader web research noMostly legitimate, but only LinkedIn substeps need it
4linkedin-invites VIP handoff to personal-one-pagerlinkedin-invites calls personal-one-pager for VIPsMedium multiplier on top of invites flowSame as aboveLegitimate, but multiplies attach pressure
5No fifth explicit hard-routed user workflow found in audited skills/configSkill audit + config audit0N/ADefault 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:


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:

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:


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.

RankPatternCount observedDenial correlationRepresentative exampleSmallest non-config change
1python3 - <<'PY' / python3 <<'PY' inline heredoc4Direct. This is the exact shape strictInlineEval is designed to stop2026-04-23 14:50:31 PDT, doc-match extraction via inline PythonReplace with read / edit / write when local file access is enough, or a checked-in helper script like workspace/scripts/extract_doc_matches.py
2Recursive grep search4None observed2026-04-23 14:50:07 PDT, grep -Rni "strictInlineEval" ... succeededPrefer read on known files, or one reusable checked-in search helper instead of ad hoc grep chains
3`find ...sed/head` file discovery pipelines2None observed2026-04-23 14:47 PDT, doc-file discovery pipelines succeededUse deterministic known paths from docs/config, or a tiny checked-in locator script
4`catsedgrep` transcript introspection pipelines2None observed2026-04-23 14:50 PDT, session transcript grep succeededUse read with offsets on the transcript file instead of shell pipelines
5Background grep plus process poll follow-up1None observed2026-04-23 14:49:46 PDT to 14:50:07 PDT, grep launched then polledRun 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:


Top 5 user-profile workflows

RankWorkflowEvidencePrompt volumeNeeds live session?Smallest non-config change
1daily-twitter-briefinghard-coded profile="user"; 3 cron windows/day; historical signed-in X timeoutHighestNo, current docs prefer host openclaw profileChange skill routing to host openclaw browser, manual login retained
2linkedin-inviteshard-coded profile="user"HighYesKeep user, but ensure one attach per run, not repeated reconnects
3personal-one-pagerhard-coded profile="user" for LinkedIn profile/postsMediumPartiallyRestrict user to the LinkedIn phase only, do web search outside it
4VIP deep-dive path from linkedin-invites to personal-one-pagerexplicit delegation in skillMedium multiplierPartiallyReuse one attached session where possible, avoid re-attaching for every VIP
5No fifth explicit route foundskill/config audit0N/ATreat 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.

  1. Stop using inline Python heredocs for routine local-file work.
  1. Move X/Twitter workflows off profile="user" unless there is a hard reason not to.
  1. Keep profile="user" only on LinkedIn workflows that truly need Pete’s live logged-in state.
  1. Avoid repeated attach cycles inside one workflow.
  1. Replace ad hoc search pipelines with deterministic helper utilities.

Evidence paths

Session and transcript evidence

Skills

Docs and runtime code

Local config


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.