[All platforms] Slack channel silently skipped — SDK rejects placeholder token before any HTTP request

[zNeill]

Description

Summary

Slack Socket Mode channel never initializes in the sandbox. The openclaw.json contains a complete Slack configuration with "botToken": "openshell:resolve:env:SLACK_BOT_TOKEN", and the OpenShell provider is registered with a valid credential. However, the Slack SDK validates the token format in-process (expects xoxb- prefix) before making any HTTP request. Since the sandbox environment variable contains the placeholder string (by design), the SDK rejects it and OpenClaw silently skips Slack initialization — no [slack] log line is ever emitted.

Root cause

OpenShell's security model intentionally keeps real secrets out of sandbox process memory:

"Child processes only see placeholder values in their environment; the proxy rewrites them to real secrets immediately before forwarding upstream."

This works for Telegram (HTTP polling — token appears in URL path /bot{TOKEN}/getUpdates, rewritten at proxy layer). It does not work for Slack because:

1. Sandbox env: SLACK_BOT_TOKEN=openshell:resolve:env:SLACK_BOT_TOKEN
2. OpenClaw reads env var or openclaw.json botToken field
3. Slack SDK validates token format in-process (checks xoxb- prefix)
4. Placeholder doesn't match → SDK skips Slack initialization
5. No HTTP request is ever made → proxy never gets a chance to replace the placeholder

Evidence

From inside sandbox:$ env | grep SLACK
SLACK_BOT_TOKEN=openshell:resolve:env:SLACK_BOT_TOKEN
$ grep -i slack /tmp/gateway.log
(only config migration line — zero [slack] initialization or connection attempts)
$ node -e "const c=require('/sandbox/.openclaw/openclaw.json'); console.log(c.channels.slack.accounts.main.botToken)"
openshell:resolve:env:SLACK_BOT_TOKEN

Meanwhile, Telegram works because its token flows through an HTTP URL path that the L7 proxy can rewrite:L7_REQUEST l7_target=/botopenshell:resolve:env:TELEGRAM_BOT_TOKEN/getMe
→ proxy rewrites to /bot/getMe
→ Telegram API returns 200

Suggested fix

Provide an opt-in mechanism for specific environment variables to be injected with real secret values instead of placeholders, for SDKs that require in-process token validation before making network calls. For example:

• A provider flag like --inject-env that tells OpenShell to pass the real value to the sandbox process
• Or a sandbox-level config that lists env vars requiring real injection
• With appropriate documentation of the security trade-off (real secret visible in process memory)

Environment

• NemoClaw v0.0.7
• OpenShell 0.0.23
• OpenClaw 2026.3.11
• Node.js 22.22.1

Bug Details

Field	Value
Priority	Unprioritized
Action	Dev - Open - To fix
Disposition	Open issue
Module	Machine Learning - NemoClaw
Keyword	NemoClaw, NEMOCLAW_GH_SYNC_APPROVAL

---

[NVB# 6056223]

[NVB#6056223]

[swinghound1]

I'm seeing the same issue trying to get NemoClaw set up on the ASUS Ascent GX10. I also would really prefer to use a password manager to store the API and Tokens instead of a flat text environment variable (which is a horrible security design).

[jyaunches]

Investigated this for DGX Spark reproducibility. The core issue is confirmed and is an OpenShell architectural limitation, not a NemoClaw code bug.

Root cause

OpenShell's security model keeps real secrets out of sandbox process memory by design — environment variables contain placeholders (openshell:resolve:env:SLACK_BOT_TOKEN) and the L7 proxy rewrites them to real values at egress. This works for Telegram (token flows through an HTTP URL path that the proxy can intercept) but fails for Slack because the Slack SDK validates the xoxb- token prefix in-process before making any network call. The placeholder is rejected and Slack initialization is silently skipped.

Why this can't be fixed in NemoClaw alone

NemoClaw passes the Slack credentials through OpenShell's provider system correctly. The problem is that OpenShell has no mechanism to inject real secret values into the sandbox environment — only placeholders. Until OpenShell adds support for real-secret injection (e.g. a --inject-env flag or a sandbox-level config for env vars requiring real values), NemoClaw cannot work around this for any SDK that does in-process token validation.

Next step

This needs coordination with the OpenShell team to add a real-secret injection option, with appropriate documentation of the security trade-off (real secret visible in process memory). Tagging this as blocked on OpenShell.

[jyaunches]

Opened upstream issue on OpenShell: NVIDIA/OpenShell#894

This tracks the architectural gap in the placeholder credential model that prevents Slack (and any SDK with in-process token format validation) from working inside sandboxes.