#12051·NemoClaw

[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

  1. Build an otherwise valid RuntimeProviderNativeArtifactBootstrapInput.
  2. Set sandboxName to abcdefghijklmnopqrst, which is 20 characters.
  3. Run the MXC native-artifact bootstrap with a spy for verifyAndCreate.
  4. 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: main at d9c33770772f06264b3a45b52fe9efc6d83aa34f
  • 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