Hybrid Inference Timeout (Docker + Mac SSH Bridge)

[urban skiff]

Hybrid Inference Timeout (Docker + Mac SSH Bridge)
Environment:

OpenClaw Version: 2026.4.16

Setup: OpenClaw Gateway running in Docker (Linux container) on Mac M4 Pro.

Connectivity: SSH Bridge to Mac Host for workspace access; Ollama running natively on Mac Host via host.docker.internal:11434.

Agent Stack: Primary (Gemini 3 Flash) -> Sub-agents (Ollama: DeepSeek-R1, Qwen 2.5 Coder).

The Problem:
When the Primary Agent attempts to use sessions_spawn to call a local sub-agent, the command often hangs or returns a timeout. I see Process still running and incomplete turn detected in the logs.

Config Snippet (openclaw.json):

JSON
{
"agents": {
"defaults": {
"subagents": { "allowAgents": ["*"] },
"timeoutSeconds": 180
},
"list": [
{ "id": "director", "model": "google/gemini-3-flash-preview" },
{ "id": "arquitecto", "model": "ollama/deepseek-r1:8b" }
]
}
}
Observations:

Permission allowAgents: ["*"] is active, but the transition from Cloud (Primary) to Local (Sub-agent) via sessions_spawn seems to hit a bottleneck.

Direct CLI commands like openclaw agents list inside the container sometimes hang or take >30s.

Is this a known issue with the Docker-to-Host network bridge latency or a potential deadlock when the agent calls the openclaw CLI from within its own execution context?

[tacit stirrup]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[frail dirge]

Exec approval is required, but native chat exec approvals are not configured on Discord.

Approve it from the Web UI or terminal UI for now. Discord supports native exec approvals for this account. Configure channels.discord.execApprovals.approvers or commands.ownerAllowFrom; leave channels.discord.execApprovals.enabled unset/auto or set it to true.

[frail dirge]

Short answer: yes, this looks more like a known OpenClaw orchestration/local-model issue than raw Docker-to-host latency.

A few important bits:

• sessions_spawn is gateway-side orchestration, it is not the agent shelling out to openclaw CLI.
• Process still running + incomplete turn detected is more consistent with a spawn/completion handoff problem, or a local model choking on the full agent prompt, than with simple host.docker.internal latency.
• Your timeout config is probably not doing what you expect: agents.defaults.timeoutSeconds is not the default timeout for spawned subagents. The docs say to use agents.defaults.subagents.runTimeoutSeconds instead.
  Docs: https://docs.openclaw.ai/tools/subagents

So I’d treat this as two likely buckets:

1. Ollama model is fine on direct calls, but slow/hangs on full OpenClaw agent runs
   OpenClaw docs explicitly call out this pattern for local/OpenAI-compatible backends, especially with tool schemas and larger prompts.
   Docs: https://docs.openclaw.ai/gateway/local-models
   Docs: https://docs.openclaw.ai/gateway/troubleshooting

2. sessions_spawn(..., mode: "run") completion handoff bug/regression

There are already reports that the child can keep running while the parent only sees a timeout/still-running state.
Related issues:
https://github.com/openclaw/openclaw/issues/24756
https://github.com/openclaw/openclaw/issues/66978

What I’d try first:

{
  agents: {
    defaults: {
      subagents: {
        allowAgents: ["*"],
        runTimeoutSeconds: 180
      }
    }

  }
}

Then isolate where it breaks:

1. openclaw status --all
2. openclaw gateway status
3. openclaw doctor
4. openclaw logs --follow

And compare these three paths:

1. Direct Ollama HTTP call to host.docker.internal:11434
2. openclaw infer model run --model ollama/deepseek-r1:8b --prompt "say OK" --json
3. Minimal sessions_spawn({ task: "say OK", model: "ollama/deepseek-r1:8b", mode: "run" })

How to read the result:

• If #2 is already slow/hanging, it is probably the local model/backend handling OpenClaw’s full prompt badly, not spawn itself. In that case, try compat.supportsTools: false on the Ollama model first.
• If #2 is fast but #3 hangs, that points much more strongly to the sessions_spawn orchestration path.
• If you recently changed allowAgents, test from a brand-new session/thread too, because older sessions can keep stale permission snapshots.

Also, DeepSeek-R1 8B / smaller Ollama models are often shaky with tool-heavy agent prompts, even when raw generation looks fine.

If you want, paste these 3 outputs and I’ll narrow it down fast:

• openclaw status --all
• openclaw infer model run --model ollama/deepseek-r1:8b --prompt "say OK" --json
• the openclaw logs --follow chunk from one failed spawn

Docs I’d use here:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/gateway/troubleshooting

• https://docs.openclaw.ai/gateway/local-models
• https://docs.openclaw.ai/tools/subagents

[frail dirge]

Small follow-up: I tried to cross-check the exact sessions_spawn / subagent references in the local docs/source here, but that local search never actually ran in this environment, so I couldn’t quote source lines directly.

The diagnosis above still stands:

• use agents.defaults.subagents.runTimeoutSeconds, not agents.defaults.timeoutSeconds
• if openclaw infer model run ... is fast but sessions_spawn hangs, suspect the spawn/completion handoff path
• if infer model run also hangs, suspect the Ollama/local-model prompt/tool compatibility path

If you paste those 3 outputs, I can narrow it down pretty quickly.