Description
A user who wants to remove NemoClaw from a host cannot do it with the documented uninstall commands. Following them in the order the product itself suggests reaches a state where every remaining uninstall command refuses to continue, and the only way to finish is to delete files by hand.
The user is not doing anything unusual. They run the uninstall the product prints when more than one gateway exists, then run the fuller uninstall the product prints when it says user data was preserved. At that point uninstall reports that the host still has a gateway environment left, refuses to clean it, and tells the user to supply a directory path. The path it asks for no longer exists, and the user never supplied one in the first place.
The wider problem is that uninstall has several independent scopes — whether to prompt, whether to purge user data, whether to cover every gateway, whether to delete models — and a user cannot tell from the output which combination will actually finish the job. Each invocation reports partial success and points at another invocation. This report is about that outcome as a whole, not about one refusal message: the host cannot be returned to a clean state through supported commands.
This is also not the first defect in this area. There are already separate open reports for uninstall refusing a gateway that was onboarding-interrupted, and for uninstall refusing a gateway that used a state-directory override. Those were filed as distinct causes with distinct triggers. The pattern suggests the cleanup contract needs to be made whole rather than patched per trigger, because each fix so far has closed one entry route into the same dead end while leaving the others open.
- Platform scope: Reproduced on DGX Station GB300 (Ubuntu 24.04, aarch64). Nothing observed is specific to Station hardware — the trigger is an ordinary multi-gateway host — but it has not been reproduced on another platform yet.
- Regression: Unknown — earlier versions not tested for this sequence.
- OpenShell issue: No
Environment
Device: NVIDIA DGX Station GB300
OS: Ubuntu 24.04.4 LTS
Architecture: aarch64
Node.js: v22.23.2
npm: 10.9.8
Docker: Docker version 29.6.1, build 8900f1d
OpenShell CLI: 0.0.116
NemoClaw: v0.0.128
OpenClaw: 2026.9.1
Steps to Reproduce
Use a host that has more than one NemoClaw gateway environment, which is an ordinary state after running more than one onboarding. Do not set any gateway port or state directory override at any point.
-
Confirm the host has several gateway environments and at least one registered sandbox.
-
Run the plain uninstall. Read its output: it reports that other gateway environments are outside this uninstall, and names the command that covers all of them.
nemoclaw uninstall --destroy-user-data
-
Run the command it just named:
nemoclaw uninstall --all-gateway-ports
Answer yes. Read the per-gateway passes and the final line.
-
Run the fuller form, combining the two scopes the product has now mentioned:
nemoclaw uninstall --yes --destroy-user-data --all-gateway-ports
-
Read what it reports, and then inspect the host to see what is actually left.
-
Try any further uninstall variant and observe whether any of them can finish.
Expected Result
A user can completely remove NemoClaw from a host using the documented uninstall commands, and end with nothing of NemoClaw left behind and no need to delete anything by hand.
That holds however many gateway environments the host has, whatever order the user runs the uninstall variants in, and whether or not they choose to purge user data. If a user runs uninstall more than once, the second run is never left worse off than the first: uninstall does not reach a state that no supported command can clear.
When uninstall stops early, it says plainly what is still present and gives a command the user can actually run to finish. It does not ask for a value the user never supplied, and it does not point at a path that no longer exists.
Actual Result
Step 3 reports the whole-host pass but does not finish cleanly. Its last line:
Could not remove gateway registration 'nemoclaw': The OpenShell gateway operation failed.
Uninstall completed with errors. Some state may remain on disk; see warnings above.
Step 4 then reports that a gateway environment the previous run already processed is still present, and refuses to clean it. For each remaining gateway:
Refusing scoped gateway cleanup because its sandbox namespace cannot be proven.
If onboarding used a gateway state override, rerun with
NEMOCLAW_OPENSHELL_GATEWAY_STATE_DIR= set to its original resolved directory.
Uninstall completed with errors. Some state may remain on disk; see warnings above.
ending with:
Whole-host uninstall is incomplete because another gateway-port environment remains.
No gateway state override was ever used on this host, so the value it asks for does not exist and never did. Checked at the time: no gateway-related override variables are set in the environment.
What is actually left on the host at that point, inspected directly:
gateway registrations none - the CLI reports no gateways found
gateway processes none
sandbox containers none
runtime state directories none
one leftover directory under the NemoClaw home, named for one gateway port, containing
only the two things the earlier pass reported it was preserving: the sandbox registry file
and the backup folder
So everything uninstall needed in order to satisfy its own later check has already been removed by its own earlier pass, while the one directory that remains is the one it now refuses to touch. Every further uninstall invocation repeats the same refusal. The only way found to clear the host was deleting that directory manually, which is not a supported command.
Also observed in the same sequence, recorded so it is not mistaken for the main point: the whole-host pass reported per-gateway steps as succeeding, including removing a gateway registration that the very next invocation then listed as still present.
Related Bugs / not duplicate of
#10665 reports the same refusal message for gateways that were onboarded with a state-directory override, where the override value genuinely existed and uninstall could not recover it. That is not this report: no override was ever used here, so there is no value to recover, and a fix that recovers a user-supplied override would leave this case unchanged.
#10544 and its later reopening report the same refusal for a gateway left behind by an interrupted onboarding. Also a different entry point into the same dead end.
The three share a symptom and differ in cause, which is the reason this report is written against the uninstall outcome as a whole rather than against one more trigger.
Logs
The console output quoted in Actual Result is the relevant output; the host inspection was
done with ordinary directory and process listing after the final uninstall attempt.
Description
A user who wants to remove NemoClaw from a host cannot do it with the documented uninstall commands. Following them in the order the product itself suggests reaches a state where every remaining uninstall command refuses to continue, and the only way to finish is to delete files by hand.
The user is not doing anything unusual. They run the uninstall the product prints when more than one gateway exists, then run the fuller uninstall the product prints when it says user data was preserved. At that point uninstall reports that the host still has a gateway environment left, refuses to clean it, and tells the user to supply a directory path. The path it asks for no longer exists, and the user never supplied one in the first place.
The wider problem is that uninstall has several independent scopes — whether to prompt, whether to purge user data, whether to cover every gateway, whether to delete models — and a user cannot tell from the output which combination will actually finish the job. Each invocation reports partial success and points at another invocation. This report is about that outcome as a whole, not about one refusal message: the host cannot be returned to a clean state through supported commands.
This is also not the first defect in this area. There are already separate open reports for uninstall refusing a gateway that was onboarding-interrupted, and for uninstall refusing a gateway that used a state-directory override. Those were filed as distinct causes with distinct triggers. The pattern suggests the cleanup contract needs to be made whole rather than patched per trigger, because each fix so far has closed one entry route into the same dead end while leaving the others open.
Environment
Steps to Reproduce
Use a host that has more than one NemoClaw gateway environment, which is an ordinary state after running more than one onboarding. Do not set any gateway port or state directory override at any point.
Confirm the host has several gateway environments and at least one registered sandbox.
Run the plain uninstall. Read its output: it reports that other gateway environments are outside this uninstall, and names the command that covers all of them.
Run the command it just named:
Answer yes. Read the per-gateway passes and the final line.
Run the fuller form, combining the two scopes the product has now mentioned:
Read what it reports, and then inspect the host to see what is actually left.
Try any further uninstall variant and observe whether any of them can finish.
Expected Result
A user can completely remove NemoClaw from a host using the documented uninstall commands, and end with nothing of NemoClaw left behind and no need to delete anything by hand.
That holds however many gateway environments the host has, whatever order the user runs the uninstall variants in, and whether or not they choose to purge user data. If a user runs uninstall more than once, the second run is never left worse off than the first: uninstall does not reach a state that no supported command can clear.
When uninstall stops early, it says plainly what is still present and gives a command the user can actually run to finish. It does not ask for a value the user never supplied, and it does not point at a path that no longer exists.
Actual Result
Step 3 reports the whole-host pass but does not finish cleanly. Its last line:
Step 4 then reports that a gateway environment the previous run already processed is still present, and refuses to clean it. For each remaining gateway:
ending with:
No gateway state override was ever used on this host, so the value it asks for does not exist and never did. Checked at the time: no gateway-related override variables are set in the environment.
What is actually left on the host at that point, inspected directly:
So everything uninstall needed in order to satisfy its own later check has already been removed by its own earlier pass, while the one directory that remains is the one it now refuses to touch. Every further uninstall invocation repeats the same refusal. The only way found to clear the host was deleting that directory manually, which is not a supported command.
Also observed in the same sequence, recorded so it is not mistaken for the main point: the whole-host pass reported per-gateway steps as succeeding, including removing a gateway registration that the very next invocation then listed as still present.
Related Bugs / not duplicate of
#10665 reports the same refusal message for gateways that were onboarded with a state-directory override, where the override value genuinely existed and uninstall could not recover it. That is not this report: no override was ever used here, so there is no value to recover, and a fix that recovers a user-supplied override would leave this case unchanged.
#10544 and its later reopening report the same refusal for a gateway left behind by an interrupted onboarding. Also a different entry point into the same dead end.
The three share a symptom and differ in cause, which is the reason this report is written against the uninstall outcome as a whole rather than against one more trigger.
Logs