exec tool can launch known-heavy upstream validation commands inside live Gateway resource domain

Summary

The exec tool allows agents to run arbitrary shell commands in the live Gateway execution context. When an agent launches heavy OpenClaw upstream validation commands — such as pnpm install, pnpm lint:core, tsgo / tsgolint, or broad vitest runs — those commands share the same systemd user cgroup as openclaw-gateway.service. Under memory pressure, this can:

1. kill transient heavy child processes and still mark the whole gateway unit as oom-kill, causing an automatic service restart,
2. or, without swap, hard-hang the host requiring manual reboot.

This was observed in production across two incidents where agent sessions independently launched corepack pnpm install && corepack pnpm exec vitest run ... && corepack pnpm lint:core on an upstream checkout within the workspace.

Relation to existing work

This issue is complementary to several existing PRs/issues:

• #70419 (merged) raises child oom_score_adj to make children more likely to be killed than the gateway. This helps kill selection but does not prevent unisolated heavy commands from starting, and systemd can still restart the gateway unit when any child inside its cgroup is killed.
• #71652 refuses local tsgo under host pressure in scripts. This is scoped to the tsgo script path, not arbitrary agent-generated exec commands.
• #75820 addresses worktree heavy-check locks. Complementary ergonomics, not exec-tool enforcement.
• #43176 caps broad find exec scans. Complementary timeout guard for a different command class.

None of these prevent arbitrary heavy validation through the exec tool itself.

Environment

• OpenClaw: 2026.4.24 (observed); latest at time of report: 2026.5.2
• OS: Ubuntu 24.04 LTS (arm64)
• Runtime: Gateway systemd user service
• Host: VPS instance

Observed behavior

Incident 1

• Agent session launched cd /tmp/openclaw-upstream-append-write-20260503 && git diff --check && corepack pnpm lint:core inside the live Gateway exec context.
• Gateway RSS was already elevated from accumulated sessions/subagents.
• Kernel OOM killed tsgolint (~3.7 GiB anon RSS) inside the openclaw-gateway.service cgroup.
• systemd marked openclaw-gateway.service as Failed with result 'oom-kill' and restarted it automatically.
• Gateway peak for the unit: ~11.0 GiB.

Incident 2

• Same thread/agent re-launched the same validation pattern (corepack pnpm install --frozen-lockfile && corepack pnpm exec vitest run ... && corepack pnpm lint:core).
• Host became unresponsive under memory pressure and required manual force reboot.
• No kernel OOM table persisted in journal (hard reboot before log flush).

In both cases, the agent was performing legitimate upstream PR follow-up validation, but the execution path placed multi-GB build/lint processes inside the same systemd cgroup as the live Gateway.

Proposed behavior

Before local host=gateway (non-sandbox, non-node) exec runs, detect whether the command matches known-heavy validation patterns:

Always-heavy:

• package-manager: pnpm/npm/yarn/bun/corepack + install, update, lint*, build*, typecheck*, test*
• direct executables: tsgo, tsgolint, oxlint, vitest, jest, mocha

Maybe-heavy:

• rg -S / rg --no-ignore / recursive grep
• git diff --stat

Allowed without guard:

• light commands (git status, targeted file reads, narrow grep)
• commands already wrapped by an isolation helper (e.g., openclaw-heavy-run -- <command>)
• commands already in an explicit resource-limited scope (e.g., systemd-run --user --scope -p MemoryMax=...)

On detection: fail closed with a clear instruction to use an isolation wrapper. Provide an environment-variable escape hatch (OPENCLAW_EXEC_HEAVY_ENFORCEMENT=off) only for explicitly approved emergency bypass.

Why this matters

• Agents can and do generate heavy validation commands autonomously during PR follow-up, issue investigation, and upstream debugging.
• Manual wrapper discipline is not scalable: sessions started before the wrapper was created continue to run commands bare.
• Without swap and without cgroup isolation, a single heavy exec can destabilize or restart the entire Gateway service.
• This is not an edge case: two incidents in ~17 hours from the same thread.

Workaround (operator-side)

Until a built-in guard exists, operators can:

1. Use a wrapper script (e.g., openclaw-heavy-run) that embeds a memory/RSS/session preflight and runs the command inside systemd-run --user --scope with MemoryMax.
2. Add zram/swap as a host-level safety buffer.
3. Instruct agents via session/system-prompt guidance to use the wrapper for heavy commands.

These are effective mitigations but rely on manual discipline and do not prevent new sessions from bypassing the wrapper.

Validation

A prepare-only source patch has been developed in a disposable upstream checkout:

• Modified src/agents/bash-tools.exec.ts to add analyzeHeavyExecCommand / rejectUnisolatedHeavyExecCommand before local gateway exec.
• Added tests to src/agents/bash-tools.exec.script-preflight.test.ts covering direct, chained, shell-wrapped, maybe-heavy, light, isolated, and execution-path blocking cases.
• pnpm exec vitest run src/agents/bash-tools.exec.script-preflight.test.ts: 2 files passed, 124 tests passed.
• git diff --check: clean.

The patch is available if maintainers want to review it.

Open questions

• Should this be an exec-tool-level guard, or a broader session-level resource policy (e.g., per-session MemoryMax via systemd-run --user --scope for all heavy exec)?
• Should the wrapper name/path be configurable via tools.exec.heavyCommandWrapper?
• Is OPENCLAW_EXEC_HEAVY_ENFORCEMENT=off the right escape-hatch name, or should it integrate with existing tools.exec.security / tools.exec.ask?