refactor(messaging): clean up provider credential hashes from SandboxEntry (registry)

[sandl99]

Summary

Removes the stale top-level SandboxEntry credential hash map that was reintroduced after the messaging credential binding migration. Sandbox registration and rebuild now rely on messaging.plan.credentialBindings[].credentialHash instead of duplicating that state.

Related Issue

Related: #4908

Changes

• Remove the duplicate credential hash map from SandboxEntry and registry registration.
• Stop building/passing the duplicate credential hash map during onboarding and stop preserving it during rebuild.
• Clean up tests and e2e fixtures/logging that referenced the removed registry field.
• Ratchet the test/onboard-messaging.test.ts file-size budget after shrinking the test file.

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

• npx prek run --all-files passes
• npm test passes
• 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)

Focused checks run after merging current origin/main:

• npm run build:cli passes
• npm run typecheck:cli passes
• npm run test-size:check passes
• git diff --check passes
• rg -n "providerCredentialHashes" --hidden --glob '!node_modules' . returns no matches
• npx vitest run test/registry.test.ts src/lib/onboard/sandbox-registration.test.ts test/onboard-messaging.test.ts test/credential-rotation.test.ts passes

Local full hook notes:

• npx prek run --all-files, the commit hook, and the pre-push hook were attempted before the merge update but were blocked by broad CLI-suite environment/timeouts unrelated to this change.

---

Signed-off-by: San Dang sdang@nvidia.com

Summary by CodeRabbit

• Bug Fixes
  • Improved sandbox image tag derivation to use actual creation output values.
  • Enhanced sandbox rebuild behavior to preserve tool gateway data when available.
• Refactor
  • Removed credential-hash persistence from sandbox registry entries and rebuild/registration flows.
• Tests
  • Updated sandbox registration unit tests to match the new registry structure.
  • Adjusted end-to-end scripts: removed credential-hash debug output and updated stored rebuild payload for Hermes.
• Chores
  • Updated CI test-file-size budget (legacy line limit).

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[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: 3f8c618a-dc9b-4cc7-9bc0-0db52a13824e

📥 Commits

Reviewing files that changed from the base of the PR and between 23ca200 and fb5e1a5.

📒 Files selected for processing (3)

• ci/test-file-size-budget.json
• src/lib/actions/sandbox/rebuild.ts
• src/lib/onboard.ts

✅ Files skipped from review due to trivial changes (1)

• ci/test-file-size-budget.json

🚧 Files skipped from review as they are similar to previous changes (1)

• src/lib/onboard.ts

---

📝 Walkthrough

Walkthrough

Removes providerCredentialHashes from the SandboxEntry interface, CreatedSandboxRegistryEntryInput type, buildCreatedSandboxRegistryEntry output, registerSandbox persistence, rebuildSandbox preserved fields, and the createSandbox caller. Also resolves the sandbox image tag from stream output instead of buildId. Tests, e2e scripts, and CI size budget are updated accordingly.

Changes

Remove providerCredentialHashes from sandbox registry

Layer / File(s)	Summary
SandboxEntry interface and registerSandbox storage src/lib/state/registry.ts	Removes the providerCredentialHashes optional field from the SandboxEntry interface and stops persisting it in registerSandbox during entry reconstruction.
Registration input type, builder, and createSandbox caller src/lib/onboard/sandbox-registration.ts, src/lib/onboard.ts	Removes providerCredentialHashes from CreatedSandboxRegistryEntryInput and buildCreatedSandboxRegistryEntry output. createSandbox now resolves the actual imageTag via resolveSandboxImageTagFromCreateOutput and drops providerCredentialHashes from the registerCreatedSandbox call.
rebuildSandbox preserved fields src/lib/actions/sandbox/rebuild.ts	preservedRegistryFields no longer carries over providerCredentialHashes; it now conditionally preserves hermesToolGateways instead.
Unit tests, e2e scripts, and size budget src/lib/onboard/sandbox-registration.test.ts, test/onboard-messaging.test.ts, test/e2e/test-channels-stop-start.sh, test/e2e/test-rebuild-hermes.sh, ci/test-file-size-budget.json	Removes providerCredentialHashes from unit test inputs and assertions, updates the non-interactive provider reuse assertion to check messagingChannels, removes the field from e2e registry payloads and debug output, and decrements the test file size budget by one line.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• NVIDIA/NemoClaw#5134: Both PRs touch the extracted sandbox registration flow in src/lib/onboard/sandbox-registration.ts and registerCreatedSandbox, with this PR specifically removing providerCredentialHashes from the constructed and registered SandboxEntry.
• NVIDIA/NemoClaw#5135: Both PRs modify the provider-credential/token preparation flow in createSandbox within src/lib/onboard.ts, where credential-related data is constructed and passed to sandbox registration.

Suggested reviewers

• cv

Poem

🐇 Hop hop, the hashes are gone today,
No more credential trails left to stray.
The registry is lighter, the sandbox clean,
imageTag resolves from the stream unseen.
One field removed, the tests all agree —
A tidier registry, just as should be! 🌿

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the primary change: removing provider credential hashes from the SandboxEntry registry object, which is the main refactoring across multiple files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ 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/remove-provider-credential-hashes

---

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@ci/test-file-size-budget.json`:
- Line 11: The file size budget increase for test/nemoclaw-start.test.ts in
ci/test-file-size-budget.json (from 5230 to 5231) is a legitimate change caused
by commit e865b500 but lacks documentation. Document this secondary file size
adjustment in the PR description or commit message to explain that the increase
results from the intentional change to remove provider credential hashes from
sandbox entries, clarifying to reviewers that this is an expected secondary
modification alongside the primary objective of adjusting
test/onboard-messaging.test.ts.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: fd1e96e8-7f21-473e-b9aa-c271b0ca8d79

📥 Commits

Reviewing files that changed from the base of the PR and between 136f656 and e865b50.

📒 Files selected for processing (9)

• ci/test-file-size-budget.json
• src/lib/actions/sandbox/rebuild.ts
• src/lib/onboard.ts
• src/lib/onboard/sandbox-registration.test.ts
• src/lib/onboard/sandbox-registration.ts
• src/lib/state/registry.ts
• test/e2e/test-channels-stop-start.sh
• test/e2e/test-rebuild-hermes.sh
• test/onboard-messaging.test.ts

💤 Files with no reviewable changes (7)

• src/lib/actions/sandbox/rebuild.ts
• test/e2e/test-channels-stop-start.sh
• test/onboard-messaging.test.ts
• src/lib/state/registry.ts
• src/lib/onboard/sandbox-registration.ts
• src/lib/onboard.ts
• src/lib/onboard/sandbox-registration.test.ts

[github-code-quality]

Code Coverage Overview

Languages: TypeScript

TypeScript / code-coverage/plugin

The overall coverage in the fix/remove-provider-... 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/remove-provider-... fb5e1a5	+/-
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/remove-provider-... branch is 44%. Coverage data for the main branch is not yet available.

Show a code coverage summary of the most covered files.

File	main	fix/remove-provider-... fb5e1a5	+/-
src/lib/state/o...oard-session.ts	—	90%	—
src/lib/inference/local.ts	—	77%	—
src/lib/sandbox/config.ts	—	72%	—
src/lib/inference/nim.ts	—	72%	—
src/lib/onboard/preflight.ts	—	64%	—
src/lib/state/sandbox.ts	—	55%	—
src/lib/actions...licy-channel.ts	—	52%	—
src/lib/onboard...er-gpu-patch.ts	—	50%	—
src/lib/policy/index.ts	—	49%	—
src/lib/onboard.ts	—	17%	—

---

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

[github-actions]

PR Review Advisor

Findings: 0 needs attention, 4 worth checking, 0 nice ideas
Since last review: 0 prior items resolved, 3 still apply, 0 new items found

Review findings

🛠️ Needs attention

• None.

🔎 Worth checking

• Source-of-truth review needed: Top-level providerCredentialHashes removal from sandbox registry entries: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: normalizeSandboxEntry() and serializeSandboxEntryForDisk() preserve unknown properties by spreading the entry, and restoreSandboxEntry() restores captured entries verbatim. The diff removes direct creation/preservation sites but not the persisted source boundary.
• Legacy providerCredentialHashes can still remain in persisted registry entries (src/lib/state/registry.ts:346): The PR removes the typed SandboxEntry field and stops new onboard/rebuild paths from writing providerCredentialHashes, but existing sandboxes.json entries that already contain the top-level field can still survive. Credential hashes are not raw tokens, but they are credential-derived metadata and can be sensitive for correlation or offline verification risks.
  • Recommendation: Scrub providerCredentialHashes at the registry source boundary, for example in normalizeSandboxEntry() and serializeSandboxEntryForDisk(), or through a focused migration helper used before save/restore. Preserve the intended nested messaging.plan.credentialBindings[].credentialHash while dropping only the legacy top-level map.
  • Evidence: normalizeSandboxEntry() returns rest or { ...entry, messaging }; serializeSandboxEntryForDisk() also spreads the entry; restoreSandboxEntry() assigns data.sandboxes[entry.name] = entry before save(). The diff removes direct providerCredentialHashes references from the type, onboarding registration, and rebuild preservation, but does not sanitize unknown legacy properties already loaded from disk.
• No regression test proves legacy credential hashes are stripped (src/lib/state/registry.ts:346): The changed tests and E2E fixtures remove references to the top-level providerCredentialHashes field, but they do not exercise the backwards-compatibility path where an existing registry file already contains that field. That is the path most likely to keep credential-derived metadata after this cleanup.
  • Recommendation: Add targeted regression coverage for legacy registry data: load/save or update a sandboxes.json entry containing top-level providerCredentialHashes and assert it is absent on disk while messaging.plan.credentialBindings[].credentialHash is preserved. If stale-recovery restore is sanitized, add a focused test proving restoreSandboxEntry() or the rebuild rollback path does not re-persist the legacy field.
  • Evidence: The diff updates sandbox-registration.test.ts, test/onboard-messaging.test.ts, and E2E fixtures by deleting old expectations/fixture fields. Existing registry tests cover messaging serialization and update paths, but no changed test starts from an on-disk legacy top-level providerCredentialHashes property and verifies it is scrubbed.
• Source-of-truth cleanup is incomplete for the removed registry field (src/lib/state/registry.ts:346): This PR treats providerCredentialHashes as an invalid duplicate top-level registry field, but the registry source-of-truth boundary still accepts and reserializes unknown fields. The patch removes creation sites rather than making the invalid persisted state impossible.
  • Recommendation: Define the source-of-truth behavior for legacy entries and enforce it at registry normalization/serialization or restore boundaries. If this cannot be fixed at the source in this PR, document the constraint and add regression coverage for the cleanup path and removal condition.
  • Evidence: The invalid state is existing persisted sandboxes.json data. The source boundary is registry load/save/restore. This PR already modifies registry.ts, but normalizeSandboxEntry(), serializeSandboxEntryForDisk(), updateSandbox(), and restoreSandboxEntry() can still carry the legacy top-level property forward.

🌱 Nice ideas

• None.

Consider writing more tests for

• **Runtime validation** — Registry load/save strips legacy top-level providerCredentialHashes from an existing sandboxes.json entry while preserving messaging.plan.credentialBindings[].credentialHash.. The behavior affects persisted registry state plus onboard/rebuild lifecycle paths. Unit-level signature changes cover new writes, but the important risk is old runtime state already on disk and recovery snapshots.
• **Runtime validation** — updateSandbox on a legacy registry entry does not re-persist top-level providerCredentialHashes.. The behavior affects persisted registry state plus onboard/rebuild lifecycle paths. Unit-level signature changes cover new writes, but the important risk is old runtime state already on disk and recovery snapshots.
• **Runtime validation** — restoreSandboxEntry or stale-recovery rollback drops top-level providerCredentialHashes from a captured legacy snapshot while preserving non-sensitive metadata such as hermesToolGateways and default restoration behavior.. The behavior affects persisted registry state plus onboard/rebuild lifecycle paths. Unit-level signature changes cover new writes, but the important risk is old runtime state already on disk and recovery snapshots.
• **Runtime validation** — registerSandbox ignores providerCredentialHashes when passed a legacy-shaped entry object via an any-cast or parsed JSON shape.. The behavior affects persisted registry state plus onboard/rebuild lifecycle paths. Unit-level signature changes cover new writes, but the important risk is old runtime state already on disk and recovery snapshots.
• **Runtime validation** — Rebuild recreate preserves hermesToolGateways and messaging credentialBindings credentialHash without reintroducing a top-level providerCredentialHashes.. The behavior affects persisted registry state plus onboard/rebuild lifecycle paths. Unit-level signature changes cover new writes, but the important risk is old runtime state already on disk and recovery snapshots.
• **No regression test proves legacy credential hashes are stripped** — Add targeted regression coverage for legacy registry data: load/save or update a sandboxes.json entry containing top-level providerCredentialHashes and assert it is absent on disk while messaging.plan.credentialBindings[].credentialHash is preserved. If stale-recovery restore is sanitized, add a focused test proving restoreSandboxEntry() or the rebuild rollback path does not re-persist the legacy field.
• **Acceptance clause:** Related: refactor(messaging): migrate conflict detection to manifest-plan architecture (phase 4a, #4392) #4908 — add test evidence or identify existing coverage. The deterministic review context did not include issue refactor(messaging): migrate conflict detection to manifest-plan architecture (phase 4a, #4392) #4908 body text or comments, so no literal linked-issue acceptance clauses were available to verify.
• **Acceptance clause:** Removes the stale top-level SandboxEntry credential hash map that was reintroduced after the messaging credential binding migration. — add test evidence or identify existing coverage. The TypeScript interface, sandbox registration input/builder, onboard caller, and rebuild preservation path no longer reference providerCredentialHashes, and repo grep found no remaining literal providerCredentialHashes references. However, legacy on-disk registry entries can still retain the unknown top-level field through registry normalization/serialization and verbatim restore.

Since last review details

Current findings:

• Source-of-truth review needed: Top-level providerCredentialHashes removal from sandbox registry entries: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: normalizeSandboxEntry() and serializeSandboxEntryForDisk() preserve unknown properties by spreading the entry, and restoreSandboxEntry() restores captured entries verbatim. The diff removes direct creation/preservation sites but not the persisted source boundary.
• Legacy providerCredentialHashes can still remain in persisted registry entries (src/lib/state/registry.ts:346): The PR removes the typed SandboxEntry field and stops new onboard/rebuild paths from writing providerCredentialHashes, but existing sandboxes.json entries that already contain the top-level field can still survive. Credential hashes are not raw tokens, but they are credential-derived metadata and can be sensitive for correlation or offline verification risks.
  • Recommendation: Scrub providerCredentialHashes at the registry source boundary, for example in normalizeSandboxEntry() and serializeSandboxEntryForDisk(), or through a focused migration helper used before save/restore. Preserve the intended nested messaging.plan.credentialBindings[].credentialHash while dropping only the legacy top-level map.
  • Evidence: normalizeSandboxEntry() returns rest or { ...entry, messaging }; serializeSandboxEntryForDisk() also spreads the entry; restoreSandboxEntry() assigns data.sandboxes[entry.name] = entry before save(). The diff removes direct providerCredentialHashes references from the type, onboarding registration, and rebuild preservation, but does not sanitize unknown legacy properties already loaded from disk.
• No regression test proves legacy credential hashes are stripped (src/lib/state/registry.ts:346): The changed tests and E2E fixtures remove references to the top-level providerCredentialHashes field, but they do not exercise the backwards-compatibility path where an existing registry file already contains that field. That is the path most likely to keep credential-derived metadata after this cleanup.
  • Recommendation: Add targeted regression coverage for legacy registry data: load/save or update a sandboxes.json entry containing top-level providerCredentialHashes and assert it is absent on disk while messaging.plan.credentialBindings[].credentialHash is preserved. If stale-recovery restore is sanitized, add a focused test proving restoreSandboxEntry() or the rebuild rollback path does not re-persist the legacy field.
  • Evidence: The diff updates sandbox-registration.test.ts, test/onboard-messaging.test.ts, and E2E fixtures by deleting old expectations/fixture fields. Existing registry tests cover messaging serialization and update paths, but no changed test starts from an on-disk legacy top-level providerCredentialHashes property and verifies it is scrubbed.
• Source-of-truth cleanup is incomplete for the removed registry field (src/lib/state/registry.ts:346): This PR treats providerCredentialHashes as an invalid duplicate top-level registry field, but the registry source-of-truth boundary still accepts and reserializes unknown fields. The patch removes creation sites rather than making the invalid persisted state impossible.
  • Recommendation: Define the source-of-truth behavior for legacy entries and enforce it at registry normalization/serialization or restore boundaries. If this cannot be fixed at the source in this PR, document the constraint and add regression coverage for the cleanup path and removal condition.
  • Evidence: The invalid state is existing persisted sandboxes.json data. The source boundary is registry load/save/restore. This PR already modifies registry.ts, but normalizeSandboxEntry(), serializeSandboxEntryForDisk(), updateSandbox(), and restoreSandboxEntry() can still carry the legacy top-level property forward.

Workflow run details

This is an automated advisory review. A human maintainer must make the final merge decision.

[github-actions]

E2E Advisor Recommendation

Required E2E: token-rotation-e2e, rebuild-hermes-e2e, messaging-providers-e2e, channels-stop-start-hermes-e2e
Optional E2E: channels-stop-start-openclaw-e2e, rebuild-openclaw-e2e, credential-sanitization-e2e

Dispatch hint: token-rotation-e2e,rebuild-hermes-e2e,messaging-providers-e2e,channels-stop-start-hermes-e2e

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• token-rotation-e2e (high): Directly validates credential hash/rotation semantics for Telegram, Discord, and Slack across re-onboard. Removing registry-level providerCredentialHashes is most likely to regress this flow if rotation detection still depends on legacy registry metadata.
• rebuild-hermes-e2e (high): Directly covers the touched rebuild path and touched test-rebuild-hermes.sh: a Hermes sandbox with messaging credentials is rebuilt non-interactively after host token removal, and the placeholder/config must survive without providerCredentialHashes preservation.
• messaging-providers-e2e (high): Validates the real provider/placeholder/L7-proxy chain for token-backed messaging credentials after onboard. The PR changes what credential metadata is written at sandbox registration, so this is the broadest provider-chain smoke for the new registry shape.
• channels-stop-start-hermes-e2e (high): Runs the touched channels stop/start E2E for Hermes, including disabling channels across rebuild and re-enabling from cached gateway credentials with no registry.providerCredentialHashes assertion.

Optional E2E

• channels-stop-start-openclaw-e2e (high): Useful adjacent coverage for the same touched stop/start script and generic onboard/registry changes, but less directly targeted than the Hermes rebuild/messaging paths changed in this PR.
• rebuild-openclaw-e2e (high): Optional parity check for the generic rebuild lifecycle after removing registry credential-hash preservation. The direct source/test changes focus on Hermes, so this is confidence coverage rather than merge-blocking.
• credential-sanitization-e2e (high): Optional security-adjacent check that credential material is still sanitized and not leaked after registry credential metadata changes. The PR removes hashes rather than adding secret exposure, so this is not primary required coverage.

New E2E recommendations

• None.

Dispatch hint

• Workflow: .github/workflows/nightly-e2e.yaml
• jobs input: token-rotation-e2e,rebuild-hermes-e2e,messaging-providers-e2e,channels-stop-start-hermes-e2e

[github-actions]

Vitest E2E Scenario Recommendation

Required Vitest E2E scenarios: token-rotation-vitest, channels-add-remove-vitest
Optional Vitest E2E scenarios: None

Dispatch required Vitest E2E scenarios:

• gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=token-rotation-vitest
• gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=channels-add-remove-vitest

Workflow run

Full Vitest E2E advisor summary

Vitest E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required Vitest E2E scenarios

• token-rotation-vitest: The PR changes onboarding, registry serialization, and rebuild handling for provider credential metadata. This free-standing Vitest job directly exercises messaging credential rotation, provider reuse/rebuild decisions, and the registry credential-hash contract most affected by removing providerCredentialHashes.
  • Dispatch: gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=token-rotation-vitest
• channels-add-remove-vitest: The PR changes rebuild/onboard registry fields used by messaging channel lifecycle flows. This free-standing Vitest job exercises channels add/remove followed by rebuild, including provider, policy, registry plan, and in-sandbox channel state preservation.
  • Dispatch: gh workflow run e2e-vitest-scenarios.yaml --ref <pr-head-ref> --field jobs=channels-add-remove-vitest

Optional Vitest E2E scenarios

• None.

Relevant changed files

• src/lib/actions/sandbox/rebuild.ts
• src/lib/onboard.ts
• src/lib/onboard/sandbox-registration.ts
• src/lib/state/registry.ts

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[github-actions]

Selective E2E Results — ✅ All requested jobs passed

Run: 27488768739
Target ref: fix/remove-provider-credential-hashes
Requested jobs: channels-add-remove-e2e,rebuild-hermes-e2e,rebuild-hermes-stale-base-e2e,messaging-providers-e2e,rebuild-hermes-e2e,channels-stop-start-openclaw-e2e,channels-stop-start-hermes-e2e,token-rotation-e2e,messaging-providers-e2e,rebuild-openclaw-e2e,credential-sanitization-e2e,
Summary: 9 passed, 0 failed, 0 cancelled, 0 skipped

Job	Result
channels-add-remove-e2e	✅ success
channels-stop-start-hermes-e2e	✅ success
channels-stop-start-openclaw-e2e	✅ success
credential-sanitization-e2e	✅ success
messaging-providers-e2e	✅ success
rebuild-hermes-e2e	✅ success
rebuild-hermes-stale-base-e2e	✅ success
rebuild-openclaw-e2e	✅ success
token-rotation-e2e	✅ success