Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

OpenClaw shows inconsistent sandbox behavior depending on the request path.

Observed pattern:

• Telegram-routed direct chat can appear to run in a host-like context
• TUI runs for the same agent are sandboxed correctly
• heartbeat / non-main runs also appear to run inside the expected sandbox

This was first reproduced with the main agent, and the same class of issue appears to affect other Telegram-routed sandboxed agents too.

Current working hypothesis: this is a channel/session-key / session-classification bug affecting Telegram-routed direct chat, rather than a general Docker sandbox failure.

Steps to reproduce

1. Configure one or more agents with Docker sandboxing enabled.
2. Use a sandboxed agent through Telegram in a normal direct-chat session.
3. Run simple environment diagnostics through the agent, for example:
   • pwd
   • ls /
   • test -d /home/openclaw && echo yes || echo no
   • mount | head
   • cat /proc/1/cgroup | head
4. Run equivalent diagnostics for the same agent through the TUI.
5. Optionally compare with a heartbeat-style or other non-main run for the same agent.
6. Observe that Telegram-routed direct chat can look host-like while TUI and heartbeat/non-main runs look sandboxed.

Expected behavior

If an agent is configured to use Docker sandboxing, the execution context should remain sandboxed regardless of interaction surface, including:

• Telegram direct chat
• TUI
• heartbeat / non-main runs

All of those paths should run inside the configured sandbox.

Actual behavior

For affected sandboxed agents:

• Telegram direct-chat exec can appear to run on the host
• TUI exec appears sandboxed
• heartbeat / non-main exec also appears sandboxed

In the Alfred reproduction:

Heartbeat-style exec:

Warning: workdir "." is unavailable; using "/home/openclaw/.openclaw/workspace"

/usr/local/bin/gog
PWD=/workspace

Telegram direct-chat exec:

/home/openclaw
bin
bin.usr-is-merged
boot
dev
etc
home
lib
lib.usr-is-merged
lib64
lost+found
media
mnt
opt
proc
root
run
sbin
sbin.usr-is-merged
snap
srv
sys
tmp
usr
var
yes
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1986604k,nr_inodes=496651,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=401000k,mode=755,inode64)
/dev/vda1 on / type ext4 (rw,relatime,discard,errors=remount-ro,commit=30)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
0::/init.scope

TUI exec for Alfred was observed to be properly sandboxed.

OpenClaw version

2026.4.21

Operating system

Ubuntu 24.04.x LTS host

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

Telegram -> OpenClaw gateway -> main agent -> openai-codex/gpt-5.4

Additional provider/model setup details

Configured auth profiles include:

• openai-codex:default using OAuth
• anthropic token profiles also present in config

Affected sandboxed agents in this environment include multiple Telegram-routed agents, not just Alfred.

Important distinction: TUI execution for Alfred behaved correctly, which suggests the bug is tied to the Telegram/inbound channel path or its session resolution rather than to sandbox containers in general.

Logs, screenshots, and evidence

## Sandbox container evidence
A live Alfred sandbox container existed and appeared sane:
- example container: `openclaw-sbx-agent-main-main-6d9217fe`

Verified characteristics:
- expected bind mounts were present
- `/workspace` existed
- `/home/openclaw` did **not** exist inside the container

This makes a simple over-broad bind-mount explanation less likely.

## Relevant runtime code clues
Most suspicious installed runtime files:
- `dist/session-key-DoN4rm2T.js`
- `dist/get-reply-BzP5ZExp.js`
- `dist/runtime-status-21FwQJGx.js`
- `dist/sandbox-B4e3wZhD.js`

Observed direct-chat session-key logic in `dist/session-key-DoN4rm2T.js`:

function resolveSessionKey(scope, ctx, mainKey) {
	const explicit = ctx.SessionKey?.trim();
	if (explicit) return normalizeExplicitSessionKey(explicit, ctx);
	const raw = deriveSessionKey(scope, ctx);
	if (scope === "global") return raw;
	const canonical = buildAgentMainSessionKey({
		agentId: DEFAULT_AGENT_ID,
		mainKey: normalizeMainKey(mainKey)
	});
	if (!(raw.includes(":group:") || raw.includes(":channel:"))) return canonical;
	return `agent:${DEFAULT_AGENT_ID}:${raw}`;
}


Observed sandbox classification logic in `dist/runtime-status-21FwQJGx.js`:

function shouldSandboxSession(cfg, sessionKey, mainSessionKey) {
	if (cfg.mode === "off") return false;
	if (cfg.mode === "all") return true;
	return sessionKey.trim() !== mainSessionKey.trim();
}


Observed sandbox gating in `dist/sandbox-B4e3wZhD.js`:

function resolveSandboxSession(params) {
	const rawSessionKey = params.sessionKey?.trim();
	if (!rawSessionKey) return null;
	const runtime = resolveSandboxRuntimeStatus({
		cfg: params.config,
		sessionKey: rawSessionKey
	});
	if (!runtime.sandboxed) return null;
	...
}


These code paths suggest a possible failure mode where Telegram-routed direct-chat session keys are misclassified, which then causes sandbox activation to be skipped.

Impact and severity

Suggested severity: high

Impact:

• breaks trust in sandbox isolation guarantees
• can expose host-like filesystem/runtime context during Telegram-routed agent use
• affects multiple sandboxed agents, not just one
• may allow tools expected to be sandbox-contained to execute with broader host visibility than intended
• creates inconsistent security posture between Telegram, TUI, and heartbeat paths

Even if TUI and heartbeat/non-main paths remain sandboxed, inconsistent enforcement is itself a serious problem because operators may assume sandboxing is uniformly active across channels.

Additional information

Relevant redacted openclaw.json excerpts:

{
  "plugins": {
    "entries": {
      "anthropic": { "enabled": true },
      "openai": { "enabled": true },
      "browser": { "enabled": true },
      "codex": { "enabled": true, "config": {} }
    }
  },
  "gateway": {
    "port": 18789,
    "mode": "local",
    "bind": "loopback",
    "auth": { "mode": "password", "password": "[REDACTED]" },
    "tailscale": { "mode": "funnel", "resetOnExit": false }
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "pairing",
      "groupPolicy": "allowlist",
      "streaming": { "mode": "off" },
      "accounts": {
        "alfred": {
          "name": "Alfred",
          "dmPolicy": "pairing",
          "botToken": "[REDACTED]",
          "groupPolicy": "allowlist",
          "streaming": { "mode": "partial" }
        }
      }
    }
  },
  "agents": {
    "list": [
      {
        "id": "main",
        "default": true,
        "name": "Alfred",
        "workspace": "/home/openclaw/.openclaw/workspace",
        "model": {
          "primary": "openai-codex/gpt-5.4",
          "fallbacks": []
        },
        "heartbeat": {
          "every": "1h",
          "target": "telegram"
        },
        "sandbox": {
          "mode": "all",
          "workspaceAccess": "rw",
          "scope": "agent",
          "docker": {
            "image": "openclaw-sandbox-browser:bookworm-slim",
            "network": "bridge",
            "user": "997:987",
            "env": {
              "XDG_CONFIG_HOME": "/workspace/.config",
              "GOG_KEYRING_PASSWORD": "[REDACTED]"
            },
            "binds": [
              "/home/openclaw/disc-mods/telegram-auth-manager/agent:/telegram-auth-manager:ro",
              "/home/openclaw/repos:/repos:rw",
              "/home/openclaw/disc-mods/chrome-extension/agent:/chrome-extension:ro",
              "/home/openclaw/disc-mods/browser-cookies/agent:/browser-cookies:ro",
              "/home/openclaw/agent-directives/common:/directives/common:ro",
              "/home/openclaw/agent-directives/agents:/directives/agents:ro",
              "/home/openclaw/disc-mods/google-suite:/google-suite:ro",
              "/home/openclaw/disc-mods/cloudflare-pages/agent:/cloudflare-pages:ro"
            ],
            "dangerouslyAllowExternalBindSources": true
          }
        },
        "tools": {
          "alsoAllow": ["cron"],
          "sandbox": {
            "tools": {
              "allow": [
                "browser",
                "group:runtime",
                "group:fs",
                "group:web",
                "group:sessions",
                "group:memory",
                "image",
                "cron",
                "nodes"
              ],
              "deny": ["gateway"]
            }
          }
        }
      }
    ]
  },
  "auth": {
    "profiles": {
      "anthropic:default": {
        "provider": "anthropic",
        "mode": "token"
      },
      "anthropic:manual": {
        "provider": "anthropic",
        "mode": "token"
      },
      "openai-codex:default": {
        "provider": "openai-codex",
        "mode": "oauth"
      }
    }
  }
}

Affected sandboxed agents in this environment include multiple Telegram-routed agents, not just Alfred.

Important distinction: TUI execution for Alfred behaved correctly, which suggests the bug is tied to the Telegram/inbound channel path or its session resolution rather than to sandbox containers in general.