fix(messaging): deny all channels when manifest declares messaging_platforms: []

[laitingsheng]

Summary

nemoclaw <name> channels list (and the onboarding messaging step) listed every OpenClaw channel for terminal-runtime agents whose manifest declared messaging_platforms: { supported: [] }. The channel-availability filter treated an empty list as "no constraint" instead of deny-all, contradicting the manifest and the downstream gates (channel-status.ts, policy-channel.ts) that already enforce the empty-list-as-deny semantics. This change aligns the two halves of the messaging stack.

Related Issue

Fixes #5664

Changes

• src/lib/messaging/utils.ts: getMessagingManifestAvailabilityContext now uses Array.isArray(...) so an explicit empty messagingPlatforms array survives as a deny-all signal; a missing field still produces null (no constraint).
• src/lib/messaging/manifest/registry.ts: ChannelManifestRegistry.listAvailable mirrors the same Array.isArray(...) guard so an empty array produces an empty Set and the filter rejects every channel.
• src/lib/messaging/manifest/registry.test.ts: split the prior catch-all test; added explicit deny-all ([]) and no-constraint (null / undefined) cases.
• src/lib/messaging/utils.test.ts (new): leaf tests for toMessagingAgentId and getMessagingManifestAvailabilityContext covering empty deny-all, populated allow-list, missing field, and Hermes identity.

Type of Change

• Code change (feature, bug fix, or refactor)
• Code change with doc updates
• Doc only (prose changes, no code sample modifications)
• Doc only (includes code sample changes)

Verification

• PR description includes the DCO sign-off declaration and every commit appears as Verified in GitHub
• Git hooks passed during commit and push, or npx prek run --from-ref main --to-ref HEAD passes
• Targeted tests pass for changed behavior
• Full npm test passes (broad runtime changes only)
• Tests added or updated for new or changed behavior
• No secrets, API keys, or credentials committed
• Docs updated for user-facing behavior changes
• npm run docs builds without warnings (doc changes only)
• Doc pages follow the style guide (doc changes only)
• New doc pages include SPDX header and frontmatter (new pages only)

---

Signed-off-by: Tinson Lai tinsonl@nvidia.com

Summary by CodeRabbit

Release Notes

• Bug Fixes

  • Messaging availability and planning now treat an explicitly provided empty platform list as deny-all (supportedChannelIds: [] filters out all results).
  • When platform constraints are missing/undefined (or set to null), they no longer impose filtering, so other criteria (such as agent selection) still apply.

• Tests

  • Added/updated unit tests to verify deny-all behavior for empty supportedChannelIds across manifest availability, compilation, workflow planning, and sandbox plan parsing.
  • Added coverage for messaging agent identity mapping and messagingPlatforms handling (empty, populated, and missing).

[github-code-quality]

Code Coverage Overview

Languages: TypeScript

TypeScript / code-coverage/plugin

The overall coverage in the fix/messaging-platfo... branch is 96%. Coverage data for the main branch is not yet available.

Show a code coverage summary of the most covered files.

File	main	fix/messaging-platfo... c401e00	+/-
nemoclaw/src/se...cret-scanner.ts	—	100%	—
nemoclaw/src/commands/slash.ts	—	100%	—
nemoclaw/src/li...bprocess-env.ts	—	100%	—
nemoclaw/src/bl...eprint/state.ts	—	98%	—
nemoclaw/src/onboard/config.ts	—	98%	—
nemoclaw/src/bl...int/snapshot.ts	—	97%	—
nemoclaw/src/bl...print/runner.ts	—	95%	—
nemoclaw/src/co...ration-state.ts	—	94%	—
nemoclaw/src/bl...ate-networks.ts	—	94%	—
nemoclaw/src/index.ts	—	94%	—

TypeScript / code-coverage/cli

The overall coverage in the fix/messaging-platfo... branch is 46%. Coverage data for the main branch is not yet available.

Show a code coverage summary of the most covered files.

File	main	fix/messaging-platfo... c401e00	+/-
src/lib/state/o...oard-session.ts	—	91%	—
src/lib/inference/local.ts	—	76%	—
src/lib/sandbox/config.ts	—	72%	—
src/lib/actions...dbox/rebuild.ts	—	67%	—
src/lib/onboard/preflight.ts	—	64%	—
src/lib/actions...licy-channel.ts	—	56%	—
src/lib/state/sandbox.ts	—	55%	—
src/lib/onboard...er-gpu-patch.ts	—	50%	—
src/lib/policy/index.ts	—	49%	—
src/lib/onboard.ts	—	18%	—

---

_{Updated June 24, 2026 00:09 UTC
Code Coverage is in Public Preview. Learn more and provide us with your feedback.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 0f8c4ac3-7f72-475f-8f86-61b587de0ac2

📥 Commits

Reviewing files that changed from the base of the PR and between c558824 and a32f2d1.

📒 Files selected for processing (2)

• src/lib/messaging/compiler/workflow-planner.test.ts
• src/lib/messaging/compiler/workflow-planner.ts

---

📝 Walkthrough

Walkthrough

Fixes a bug where messagingPlatforms: [] was treated as no constraint rather than deny-all. Implementation files across the messaging flow—utils, registry, compiler, workflow planning, and plan validation—replace non-empty-length checks with Array.isArray, and comprehensive tests validate the resulting semantics at each layer.

Changes

Empty messagingPlatforms deny-all fix

Layer / File(s)	Summary
Input context derivation with Array.isArray guard src/lib/messaging/utils.ts, src/lib/messaging/utils.test.ts	getMessagingManifestAvailabilityContext replaces length > 0 with Array.isArray, so an explicit empty messagingPlatforms array yields supportedChannelIds: [] (deny-all) instead of null (no constraint). New test file covers agent ID fallback, empty-array, populated-array, and null/undefined cases, plus agent identity preservation.
Registry filtering by supported channels src/lib/messaging/manifest/registry.ts, src/lib/messaging/manifest/registry.test.ts	ChannelManifestRegistry.listAvailable applies the same Array.isArray pattern, producing an empty Set for empty supportedChannelIds. Test updates clarify the "explicit platform support lists" wording and add deny-all and no-constraint cases.
Compiler manifest resolution src/lib/messaging/compiler/types.ts, src/lib/messaging/compiler/manifest-compiler.ts, src/lib/messaging/compiler/manifest-compiler.test.ts	ManifestCompilerContext.supportedChannelIds type now accepts explicit null. resolveManifests switches to Array.isArray, denying all manifests when empty. Test asserts compilation rejection when supportedChannelIds: [] conflicts with configured channels.
Workflow planning context and helper function src/lib/messaging/compiler/workflow-planner.ts	MessagingWorkflowPlannerBuildContext and MessagingWorkflowPlannerSandboxContext types accept explicit null. Helper function switches to Array.isArray logic. Context forwarding in credentialAvailabilityFromSandboxEntry and readSandboxEntryPlan expanded to include supportedChannelIds.
Workflow planning tests for deny-all scenarios src/lib/messaging/compiler/workflow-planner.test.ts	Tests verify deny-all behavior for persisted-plan rebuild and stop/start/remove mutations when supportedChannelIds: []. Additional test asserts buildPlan rejects with "Unsupported messaging channel(s)" when empty supportedChannelIds excludes all configured channels.
Plan validation and deny-all handling src/lib/messaging/plan-validation.ts, src/lib/messaging/plan-validation.test.ts	parseSandboxMessagingPlan builds the supported Set whenever supportedChannelIds is an array, turning empty-array behavior from "no filter" to "match nothing". Test verifies deny-all result for persisted channels when supportedChannelIds: [].

Sequence Diagram

sequenceDiagram
  participant AgentManifest
  participant getMessagingManifestAvailabilityContext
  participant ChannelManifestRegistry
  participant ManifestCompiler
  participant WorkflowPlanner
  AgentManifest->>getMessagingManifestAvailabilityContext: messagingPlatforms: []
  getMessagingManifestAvailabilityContext->>getMessagingManifestAvailabilityContext: Array.isArray check
  getMessagingManifestAvailabilityContext->>ChannelManifestRegistry: supportedChannelIds: []
  ChannelManifestRegistry->>ChannelManifestRegistry: Array.isArray → empty Set
  ChannelManifestRegistry->>ManifestCompiler: no manifests pass filter
  ManifestCompiler->>ManifestCompiler: Array.isArray check in resolveManifests
  ManifestCompiler->>WorkflowPlanner: deny-all enforced
  WorkflowPlanner->>WorkflowPlanner: Array.isArray check activates filter
  WorkflowPlanner-->>AgentManifest: reject unsupported channels

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐇 An empty array whispered "I'm null, let me through!"
But the rabbit said "no—I know what you do."
With isArray checked, the deny becomes clear,
Empty means nothing—no channels appear!
From utils to plans, the fix now runs true,
The manifest's law flows the whole pipeline through. 🐾

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title accurately and concisely describes the main change: fixing the behavior where empty messaging_platforms arrays are now treated as deny-all instead of no-constraint.
Linked Issues check	✅ Passed	All code changes directly address the requirements from issue #5664: empty messaging_platforms arrays are now treated as deny-all signals via Array.isArray() checks throughout the codebase, with comprehensive test coverage added.
Out of Scope Changes check	✅ Passed	All changes are scoped to the messaging manifest filtering logic and its tests; no unrelated modifications detected outside the scope of fixing the empty-platforms deny-all behavior.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/messaging-platforms-empty-deny

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

PR Review Advisor — No blocking findings

Merge posture: No blocking advisor findings
Primary next action: Add or justify PRA-T1 and any related test follow-ups.
Open items: 0 required · 0 warnings · 0 suggestions · 3 test follow-ups
Since last review: 0 prior items resolved · 0 still apply · 0 new items found

Action checklist

• PRA-T1 Add or justify test follow-up: Runtime validation
• PRA-T2 Add or justify test follow-up: Runtime validation
• PRA-T3 Add or justify test follow-up: Runtime validation

Test follow-ups to resolve or justify

If these cover changed behavior, prefer adding them in this PR; otherwise state why existing coverage is enough or link the follow-up.

• PRA-T1 Runtime validation — Add or identify a setupMessagingChannels non-interactive test where agent.name is langchain-deepagents-code and messagingPlatforms is [] that asserts the function returns [] and MessagingSetupApplier does not retain staged messaging plan env.. Changed unit coverage is strong and directly covers the security-sensitive caller/callee contracts. Runtime-style coverage would still increase confidence that CLI/onboarding wrappers pass the fixed availability context all the way to user-visible behavior, but no code-review blocker was found.
• PRA-T2 Runtime validation — Add or identify a listSandboxChannels test for a sandbox whose resolved agent is langchain-deepagents-code that asserts the output contains the sandbox header but no telegram, discord, slack, wechat, or whatsapp channel rows.. Changed unit coverage is strong and directly covers the security-sensitive caller/callee contracts. Runtime-style coverage would still increase confidence that CLI/onboarding wrappers pass the fixed availability context all the way to user-visible behavior, but no code-review blocker was found.
• PRA-T3 Runtime validation — Add or identify a loadAgent('langchain-deepagents-code') manifest contract assertion that messagingPlatforms is [] to anchor the manifest source-of-truth used by the messaging availability path.. Changed unit coverage is strong and directly covers the security-sensitive caller/callee contracts. Runtime-style coverage would still increase confidence that CLI/onboarding wrappers pass the fixed availability context all the way to user-visible behavior, but no code-review blocker was found.

Workflow run details

This is an automated, non-binding review; it still expects maintainers and agents to respond to each required or warning item. Treat suggestions as current-PR improvements when they touch changed code; defer only with maintainer rationale or a linked follow-up. A human maintainer must make the final merge decision.

[github-actions]

E2E Advisor Recommendation

Required E2E: messaging-providers-e2e, channels-add-remove-e2e, channels-stop-start-openclaw-e2e
Optional E2E: channels-stop-start-hermes-e2e, rebuild-openclaw-e2e

Dispatch hint: messaging-providers-e2e,channels-add-remove-e2e,channels-stop-start-openclaw-e2e

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• messaging-providers-e2e (medium): Required because the manifest compiler and registry changes can change selected messaging manifests, credential provider bindings, placeholder handling, and network policy output. This job validates the Telegram/Discord/Slack provider, placeholder, credential isolation, and L7 rewrite chain in a real sandbox.
• channels-add-remove-e2e (medium): Required because workflow-planner changes affect channel add/remove plan construction and persisted credential reuse. This job exercises real add/remove lifecycle behavior with messaging channels and rebuild reuse of gateway-held credentials.
• channels-stop-start-openclaw-e2e (medium): Required because the PR changes stop/start mutation planning from persisted sandbox entries by filtering parsed plans through supportedChannelIds. This job validates real OpenClaw channel stop/start behavior across rebuild and cached credential reattachment.

Optional E2E

• channels-stop-start-hermes-e2e (medium): Optional cross-agent confidence because the supportedChannelIds/agent filtering logic is generic and also applies to Hermes manifests and persisted Hermes messaging plans.
• rebuild-openclaw-e2e (medium): Optional additional confidence for persisted plan hydration and rebuild behavior, which is adjacent to the parseSandboxMessagingPlan and buildRebuildPlanFromSandboxEntry changes.

New E2E recommendations

• messaging platform deny-all support (high): Existing E2E jobs validate normal configured messaging channels, but do not appear to explicitly exercise an agent descriptor or persisted sandbox entry with messagingPlatforms/supportedChannelIds set to an empty array. Add live coverage that verifies deny-all suppresses channel availability, avoids provider/policy creation, and safely drops persisted messaging plans during rebuild and channel mutations.
  • Suggested test: Add a selective E2E job for explicit empty messagingPlatforms/supportedChannelIds deny-all behavior across onboarding availability, rebuild, and channel start/stop/remove flows.

Dispatch hint

• Workflow: nightly-e2e.yaml
• jobs input: messaging-providers-e2e,channels-add-remove-e2e,channels-stop-start-openclaw-e2e

[github-actions]

Vitest E2E Scenario Recommendation

Required Vitest E2E scenarios: messaging-providers-vitest, channels-add-remove-vitest, channels-stop-start-vitest
Optional Vitest E2E scenarios: messaging-compatible-endpoint-vitest

Dispatch required Vitest E2E scenarios:

• gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=messaging-providers-vitest
• gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=channels-add-remove-vitest
• gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=channels-stop-start-vitest

Workflow run

Full Vitest E2E advisor summary

Vitest E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required Vitest E2E scenarios

• messaging-providers-vitest: Messaging manifest availability, compiler support filtering, and channel plan validation changed. The messaging providers Vitest job is the broad live messaging path for provider/manifest/placeholder/runtime contracts across supported messaging channels.
  • Dispatch: gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=messaging-providers-vitest
• channels-add-remove-vitest: The workflow planner and persisted messaging plan parsing changed for supportedChannelIds handling. This job exercises live channel add/remove, rebuild, registry, and messaging plan persistence boundaries for Telegram.
  • Dispatch: gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=channels-add-remove-vitest
• channels-stop-start-vitest: The PR changes persisted plan validation and workflow planner mutation paths used by channel stop/start operations, including support-filter handling from sandbox entries.
  • Dispatch: gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=channels-stop-start-vitest

Optional Vitest E2E scenarios

• messaging-compatible-endpoint-vitest: Adjacent coverage for Telegram messaging configuration during onboarding with an OpenAI-compatible endpoint; useful if reviewers want another live compiler/manifest integration path without real messaging secrets.
  • Dispatch: gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=messaging-compatible-endpoint-vitest

Relevant changed files

• src/lib/messaging/compiler/manifest-compiler.ts
• src/lib/messaging/compiler/types.ts
• src/lib/messaging/compiler/workflow-planner.ts
• src/lib/messaging/manifest/registry.ts
• src/lib/messaging/plan-validation.ts
• src/lib/messaging/utils.ts