Summary

The Slack channel (added via nemoclaw <sandbox> channels add slack) consistently fails to handle incoming events. The NemoClaw gateway HTTP proxy rejects the CONNECT method, while @slack/bolt (via @slack/web-api and Node 22's bundled undici) issues CONNECT to tunnel HTTPS whenever HTTPS_PROXY is set in the sandbox environment. There appears to be no configuration path that makes this work today.

Direct GET/POST traffic to slack.com is allowed; only the CONNECT tunnel used by the Bolt event-callback handler is denied. The L4 OPA engine accepts the connection, but the L7 layer rejects CONNECT specifically.

Symptoms

After sending a DM to the bot, nemoclaw <sandbox> logs --follow shows:

[WARN]  bolt-app Authorization of incoming event did not succeed. No listeners will be called.
[ERROR] bolt-app Error: An HTTP protocol error occurred: statusCode = 403
    code: 'slack_bolt_authorization_error',
    statusCode: 403,
    statusMessage: 'Forbidden',
    body: {
      detail: 'CONNECT slack.com:443 not permitted by policy',
      error: 'policy_denied'
    },
[ERROR] An unhandled error occurred while Bolt processed (type: event_callback, error: ...)

For comparison, during channel startup a direct (non-CONNECT) call succeeds:

[INFO] HTTP:POST [INFO] ALLOWED POST http://slack.com:443/api/auth.test [policy:slack engine:l7]

The L4 engine allows the socket open, but the L7 layer denies CONNECT:

[OCSF] NET:OPEN [INFO] ALLOWED /usr/local/bin/node(290) -> slack.com:443 [policy:slack-custom engine:opa]
...
CONNECT slack.com:443 not permitted by policy

So the failure is specifically on the CONNECT verb at L7, not on reachability.

Workarounds attempted (all failing)

• policy-remove slack && policy-add slack to refresh the built-in preset — no effect.
• Custom YAML preset via policy-add --from-file granting tls: skip, access: full for slack.com:443, api.slack.com:443, hooks.slack.com:443, wss-primary.slack.com:443, wss-backup.slack.com:443. Schema rejected several variants; eventually accepted but reported as "recorded locally, not active on gateway" — i.e. sync drift.
• shields down --policy permissive --timeout 30m — CONNECT is still denied.

While investigating, policy-list exposed broader drift between local recorded state and gateway-applied policy, e.g.:

discord — Discord API, gateway, and CDN access (active on gateway, missing from local state)

This suggests an underlying sync issue worth tracking separately.

Suggested fixes (starting points for discussion)

1. Make the CONNECT method a first-class option in the policy preset schema, e.g. methods: [GET, POST, CONNECT] or an explicit allow_connect: true.
2. Provide a per-channel toggle (env var or channel config) to opt out of HTTPS_PROXY injection, so undici makes direct TLS calls and never issues CONNECT.
3. Document the recommended undici Agent / proxy configuration for channel runtimes that wrap third-party SDKs (Bolt, Discord, etc.).

Why this matters

With the current behavior, the Slack channel cannot service any event-driven flow (DMs, mentions, slash commands routed through events). The non-CONNECT auth.test succeeds during startup, which makes the channel look healthy until the first event arrives, so the failure mode is easy to miss in pre-flight checks. A documented or supported way to permit CONNECT (or to bypass HTTPS_PROXY for trusted hosts) would unblock the Slack channel out of the box.

Reproduction Steps

1. Fresh Debian 12 host with Docker and Node 22.
2. nemoclaw onboard --non-interactive --name testbot with NEMOCLAW_PROVIDER=anthropic, ANTHROPIC_API_KEY=..., TELEGRAM_BOT_TOKEN=....
3. Create a Slack app from a manifest with socket mode and a connections:write app-level token.
4. SLACK_BOT_TOKEN=xoxb-... SLACK_APP_TOKEN=xapp-... nemoclaw testbot channels add slack.
5. Send a DM to the bot in Slack.
6. nemoclaw testbot logs --follow — observe the failure pattern above.

Environment

• NemoClaw v2026.4.24 (nemoclaw <sandbox> status reports Agent: OpenClaw v2026.4.24)
• Node.js v22.22.2 inside the sandbox (path observed in the trace: /usr/local/bin/node(290) ... openclaw-unknown-.../node_modules/@slack/web-api/dist/WebClient.js)
• Host: Debian 12 on a GCP Compute Engine VM (e2-standard-4), MTU 1460 on docker0
• Sandbox provider: anthropic (claude-sonnet-4-6)
• Slack app: socket mode enabled, scopes chat:write, app_mentions:read, channels:history, im:history, etc.; connections:write app-level token

Debug Output

Logs

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate