NVIDIA/NemoClaw

Description A sandbox post-create failure can print Docker GPU patch failed even when GPU passthrough is disabled and the selected operation is the persistent sandbox startup command. The observed macOS failure reported: Docker GPU patch failed. Could not transfer managed-startup receipt to Docker: ... patched_create_option=persistent sandbox startup command The same output recommends --no-gpu, although the run already has no sandbox GPU. This sends the user toward an unrelated workaround and hides the operation that failed. Current code routes several post-create operations through shared Docker GPU patch diagnostics. PR #11909 changes that ownership and removes most standard managed-bootstrap orchestration. Implementation must wait for #11909 and must use the remaining post-create paths after that PR merges. Dependency Blocked by #11909. After #11909 merges, confirm that a non-GPU post-create path can still produce the misleading headline. If no supported path remains, close this is

Description After provider credential validation fails, onboarding tells the user to re-enter the API key and then immediately says not to paste the key: NVIDIA Endpoints authorization failed. Re-enter the API key or choose a different provider/model. ⚠️ Do NOT paste your API key here — use the options below: Options: retry (re-enter key), back (change provider), exit [retry]: The warning applies to the options prompt, not to the masked credential prompt that opens after the user chooses retry. The current wording does not explain that transition. A user can reasonably conclude that onboarding requests a key and forbids entering it at the same time. Issue #9557 and PR #9607 fixed navigation and credential-handling behavior at the re-entry prompt. This issue changes the remaining user-facing text. It does not change credential validation or storage. Expected result The options prompt tells the user to choose retry to open the secure credential prompt. The secure prompt then requ

Problem The Hermes ACP connection path uses the host-side gateway registry as an authority before it recovers and queries the live OpenShell gateway. That ordering makes cached lifecycle observations a prerequisite for reaching the system that owns the live state. The registry compatibility check currently includes the agent version, OpenShell version, NemoClaw version, lifecycle generation, live identity fingerprint, gateway association, and state root. Some bootstrap information is necessary while a gateway is unavailable, but cached runtime identity and lifecycle observations should not independently decide whether recovery is allowed. This became visible during the fa3e36f5f350d8c1d61fc48bc9b1573707694b99 main E2E incident: Push run: https://github.com/NVIDIA/NemoClaw/actions/runs/34788709180 Repeated Hermes job: https://github.com/NVIDIA/NemoClaw/actions/runs/34788709180/job/103823368458 Related refactor: #11163 The test intentionally stopped the OpenShell gateway and invoked ne

Objective Reduce repeated root-test setup without hiding scenario inputs or assertions. Sequential PRs Add an onboarding child-process harness for four pilot suites. Add an in-memory onboarding-machine runtime fixture. Add an installer checkout and npm-stub builder. Add a fresh-object OpenClaw environment fixture and canonical corporate-CA test asset. Expected combined net reduction: 1,130–1,700 LOC. Relationships Parent Epic: #8345 Parent hierarchy: #8345 is a child of #8281. Blocked by: None. Work can start independently. Blocks: None. Related work: #8290 covers plugin migration and runner fixtures; it does not own these root-test fixtures. Acceptance criteria Helpers own setup mechanics only. Scenario inputs and behavior assertions remain in each test. Helpers return fresh mutable objects. Helpers restore environment and global state. No generic mock DSL or automatic behavioral default is added. Each migration has a negative net LOC delta. Validation Run affected integration

Problem Statement Applications inside a NemoClaw/OpenShell sandbox often see only a high-level transport error such as fetch failed, request timed out, or disconnect/reset before headers. That output does not identify whether the failure occurred during policy evaluation, proxy CONNECT, TLS setup, upstream connection, response headers, or an application protocol exchange. This is especially difficult when the same service works through a direct connection but fails through the managed proxy. Operators currently have to correlate agent logs, CLI output, and OpenShell audit logs manually, often without a shared request identifier. MCP is the first concrete consumer, but the diagnostic contract should be reusable by messaging, provider, webhook, package-fetch, and other managed outbound transports. Desired Behavior Provide a reusable, failure-only managed-transport diagnostic facility that emits a redacted structured event and a correlation identifier across the application and OpenShell