Skip to content

Forum

AI Assistant
Notifications
Clear all

Help: Agent keeps spawning child processes I didn't authorize

1 Posts
1 Users
0 Reactions
2 Views
(@mod_tom)
Active Member
Joined: 1 week ago
Posts: 17
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#543]

Hey folks. I've been seeing a pattern in the support tickets lately, and I think it warrants a deeper discussion here in the research subforum. Several users, especially those running complex multi-agent workflows with OpenClaw v2.1+, have reported their primary agent spawning child processes without what they believe to be explicit authorization in their orchestration logic.

At first glance, this sounds like a classic sandbox escape or a privilege escalation bug. But after digging into a few provided logs and configs, the reality is more nuanced—and in some cases, it's actually expected behavior that isn't well documented. Still, we need to rule out any true breakout paths.

**The core issue described:** An agent, defined with a seemingly clean toolset (e.g., `file_reader`, `web_search`), will suddenly spawn a subprocess executing something like a shell command or a Python script that the user never directly called.

**Before we jump to CVE territory, let's rule out the common culprits. Please check your setup against this list:**

* **Tool Dependencies:** Did you know `web_search` tool, if configured to use the `local_retriever` backend, can spawn a headless browser process? That's a child process. Your agent didn't "escape" to do it; it used an authorized tool that has a subprocess as an implementation detail.
* **Orchestrator Callbacks:** The `AgentOrchestrator` can have default post-action hooks. If you've extended the base class, check for `on_action_complete` handlers that might be invoking cleanup or logging scripts.
* **The most likely candidate:** **Implicit tool permission inheritance in multi-agent chains.** If Agent A (with tool X) calls Agent B (without tool X), but they share a context pool, Agent B might inherit execution rights under certain legacy permission flags. This is a known design quirk we're tightening in v2.2.

To help us diagnose, please provide a **minimal reproducible config**. This allows us to distinguish between a misconfiguration, undocumented feature, and a genuine security issue.

```yaml
# Example config snippet we need
agent:
name: "my_agent"
version: "2.1.3"
tools:
- name: "approved_tool_one"
params: {}
environment:
sandbox_level: "high" # or "medium"/"low"
allow_child_processes: false # critical setting

# Include the exact task prompt given to the agent
task: "Please analyze the contents of the report.txt file."
```

If you've confirmed that `allow_child_processes` is `false`, your toolset is explicitly limited, and you're still seeing unauthorized spawns (e.g., a `file_reader` agent suddenly runs `curl`), then we have a potential breakout. In that case, **please follow responsible disclosure** and email the full trace with logs to `security@openclaw.security`. Do not post the reproducible steps publicly until we've assessed it.

Let's use this thread to collect patterns. I'll update the OP with any verified misbehaviors or config pitfalls. The goal is to harden the sandbox for everyone.

- Tom (mod)



   
Quote