[Windows][Onboard] MXC bootstrap accepts over-length OpenShell sandbox names
Author: ericksoaCreated Sep 18, 2026Updated Sep 18, 2026
Investigation Summary
- OpenShell 0.0.116 accepts routable sandbox names of at most 19 characters.
- NemoClaw's shared CLI, installer, plugin, config, and workflow boundary already enforce that limit.
- The later MXC native-artifact bootstrap added a separate
^[a-z][a-z0-9-]{0,62}$check. - A 20-character lowercase name passes the MXC bootstrap check and reaches the provider create boundary, where OpenShell must reject it.
- No existing issue covers this post-MXC regression; #3638 and #8523 addressed the earlier shared boundary.
Description
The Windows MXC native-artifact bootstrap accepts sandbox names up to 63 characters. OpenShell 0.0.116 limits routable sandbox names to 19 characters because it composes workspace, sandbox, and service segments into one DNS label.
MXC bootstrap input must use NemoClaw's canonical OpenShell sandbox-name contract. It must reject an over-length name before it calls the provider create operation.
Reproduction Steps
- Build an otherwise valid
RuntimeProviderNativeArtifactBootstrapInput. - Set
sandboxNametoabcdefghijklmnopqrst, which is 20 characters. - Run the MXC native-artifact bootstrap with a spy for
verifyAndCreate. - Observe that the current 63-character regex accepts the input and calls
verifyAndCreate.
Expected result: NemoClaw rejects the input before the create boundary, and verifyAndCreate is not called.
Environment
- OS: Any for the deterministic boundary test; the affected provider targets Windows MXC
- OpenShell: 0.0.116
- NemoClaw:
mainatd9c33770772f06264b3a45b52fe9efc6d83aa34f - Docker: not required
Debug Output
Not applicable. The mismatch is deterministic in src/lib/onboard/runtime-provider/mxc-bootstrap.ts.
Checklist
- I confirmed this bug is reproducible
- I searched existing issues and this is not a duplicate
Source: NVIDIA/NemoClaw