Declare the OpenShell Gateway Lifecycle Authority
This page covers the host-side OpenShell gateway that NemoClaw uses for OpenClaw, Hermes, and LangChain Deep Agents Code sandboxes. It does not describe the in-sandbox agent gateway used by OpenClaw and Hermes. Deep Agents Code has no in-sandbox agent gateway.
At every point, exactly one component owns the OpenShell gateway lifecycle.
Platform images sometimes supervise the gateway with their own service. Without an explicit authority, both the platform and NemoClaw can try to own the same process and port. The gateway-management contract prevents that conflict by making NemoClaw manage the gateway or attach to a gateway that an external supervisor owns.
Management modes
Choose the mode that matches the component responsible for process lifecycle operations.
When nothing is declared, NemoClaw keeps its existing managed behavior. On Linux, the installer selects a packaged gateway user service only after the systemd user manager reports the effective unit and executable identity. The installer verifies that identity and the gateway version before NemoClaw uses the service. It does not parse a static package unit as the effective service identity.
If the systemd user manager reports a recognized unavailable condition, the installer can keep the existing standalone gateway lifecycle.
When NEMOCLAW_GATEWAY_PORT selects port 8080 and neither gateway service has a .wants, .requires, or .upholds activation link, the standalone gateway keeps port 8080.
The installer stops when SYSTEMD_UNIT_PATH overrides those paths because it cannot verify the activation state.
When NEMOCLAW_GATEWAY_PORT is unset, one qualified package-service activation can make the installer move the standalone NemoClaw gateway to a port from 8990 through 9005.
Qualification requires one canonical openshell-gateway.service link, a trusted package unit without drop-ins, and an effective OPENSHELL_SERVER_PORT=8080 setting.
The installer rejects reserved or configured service ports, existing listeners, gateway registrations, and port-scoped NemoClaw state.
It also rejects a candidate when no supported listener probe can conclusively confirm that the port is unused.
Installation stops when no candidate passes.
It exports the selected port and writes a pending port identity before onboarding runs or is deferred.
Successful installer-driven or direct CLI onboarding promotes that identity to the completed marker. Deferred or interrupted onboarding keeps the pending identity so a later installer or CLI process can reach the same state.
Later NemoClaw commands restore either recorded identity when NEMOCLAW_GATEWAY_PORT is unset, while an explicit supported value remains authoritative.
A supported explicit non-default port remains authoritative and uses its detached lifecycle without automatic selection.
An explicit port of 8080, an ambiguous activation, or an unqualified service still stops installation until you restore the user manager or resolve the service through its owner.
Other service query errors, malformed metadata, untrusted paths, executable failures, and version mismatches stop installation.
Declare the mode
Set NEMOCLAW_GATEWAY_MANAGEMENT to the path of a JSON declaration.
An externally supervised declaration identifies the local endpoint, state directory, systemd unit, and executable.
A managed declaration omits endpoint, stateDir, and supervisor.
The declaration uses the following fields.
requiredCapabilities is checked against the capabilities implemented by this NemoClaw build.
OpenShell does not expose capability discovery, so this field does not probe or attest capabilities on the running gateway.
The listener, supervisor, identity, and health checks below validate the live gateway separately.
The endpoint port must match NEMOCLAW_GATEWAY_PORT.
When the endpoint omits a port, http resolves to port 80 and https resolves to port 443 for this comparison.
Onboarding rejects a mismatch before making a health request or inspecting the host listener because validating one endpoint and operating a different gateway would break the authority boundary.
The declaration is versioned and secret-free. NemoClaw rejects unknown fields and unsupported capabilities instead of ignoring them. The authority may be persisted in checkpoints, diagnostics, and machine events, so do not place credentials or other secrets in it.
Only systemd supervisors are supported in version 1. NemoClaw verifies the listener executable, the declared system or user manager scope, and membership in the declared unit’s cgroup. A matching executable alone is not sufficient because the same binary can run outside the declared unit.
Configure HTTPS health checks
An HTTPS endpoint requires the external gateway’s mTLS client files under the declared stateDir.
All three paths must be readable regular files.
NemoClaw uses this bundle for the mTLS gRPC health request at the declared endpoint path /openshell.v1.OpenShell/Health.
For an HTTP endpoint, NemoClaw sends the readiness request to the declared origin.
Validate and attach the gateway
NemoClaw validates external authority before provider, policy, sandbox, or sandbox-registry mutations.
NemoClaw requires systemd to confirm that the declared unit is active.
It checks that exactly one live process holds the configured port.
The process identity must remain stable while NemoClaw reads /proc evidence and confirms the listener a second time.
The process must belong to the unit’s cgroup under the declared systemd manager scope, and its executable must match execPath.
The endpoint must answer its health check.
After validation, NemoClaw registers the endpoint under the canonical gateway name and selects it as the active OpenShell gateway.
Immediately before registration, NemoClaw reloads the authority and rejects any change from the authority bound to the run.
Port 8080 uses the name nemoclaw, and another port uses nemoclaw-<port>.
NemoClaw verifies the named and active registrations before advancing to provider selection.
It then repeats the health, supervisor, listener, executable, cgroup, and process identity checks and compares them with the initial evidence.
If registration, selection, or repeated validation fails, NemoClaw removes the attempted registration and stops before provider selection.
Onboarding fails when any of the following conditions applies:
- The endpoint port differs from the gateway port for this process.
- A required capability is unsupported.
- The declared supervisor is inactive, or systemd cannot confirm its active state.
- Nothing is listening on the declared endpoint.
- The listener set cannot be enumerated completely.
- NemoClaw cannot identify a listener process for the occupied port.
- More than one process holds the port.
- The listener process or listener set changes during identity verification.
- The listener does not belong to the declared systemd unit.
- The listener executable does not match
execPath. - The endpoint does not answer the required health check.
- The authority differs from the authority already bound to this run or checkpoint.
Preserve authority across resume
NemoClaw records the resolved, secret-free authority in onboarding checkpoint schema version 2 before gateway preflight.
The record includes the canonical gateway name and port, mode, source, endpoint, state directory, supervisor identity, and required capabilities.
Resume resolves the current authority again and compares the complete record with the checkpoint. If any value changes, including the per-port gateway binding, resume fails before gateway effects and directs you to start a fresh onboarding run. A completed gateway step does not bypass listener, supervisor, identity, health, registration, or checkpoint validation.
Migrate Managed Authority During Rebuild and Full Uninstall
A transactional sandbox rebuild can adopt one managed lifecycle change when the recorded package-managed service is no longer selected and NemoClaw selects its standalone gateway. NemoClaw records the standalone authority in the replacement journal before it changes managed MCP state, providers, or deletes the sandbox. Full uninstall can also complete gateway teardown when an earlier uninstall step already removed the package-managed service and the same NemoClaw-managed gateway resolves as standalone. These exceptions do not apply to credential mutation, ordinary gateway teardown outside full uninstall, an authority declaration change, the reverse transition to a package-managed service, or other authority drift. Those operations continue to fail closed before gateway effects.
Inspect the selected authority
Run nemoclaw status to see the management mode and redacted owner identity selected by the last onboarding run.
The JSON form includes the same secret-free fields under gatewayAuthority.
In nemoclaw-managed mode, gatewayAuthority.supervisor is null.
The owner source is declared when a declaration selected that mode; without a declaration it is the resolved lifecycle source, packaged-service or standalone.
In externally-supervised mode, the owner is the declared supervisor kind, serviceName, and execPath.
nemoclaw debug also records gatewayAuthority in onboard-session-summary.txt.
The status and debug views omit the external state directory and never include credential values.
Keep external lifecycle paths inert
External supervision prevents every NemoClaw gateway lifecycle path from affecting the supervised process. Preflight skips stale gateway cleanup, orphaned container cleanup, volume removal, and registry cleanup associated with a NemoClaw-owned runtime. The shared gateway start guard blocks normal starts. The external attachment path has no standalone fallback. Recovery and rebuild guard every start branch, including non-default port recovery. The gateway state handler validates and attaches instead of starting, stopping, restarting, destroying, or replacing the gateway.
Stop, final-sandbox cleanup, and uninstall reload the declaration before gateway teardown. When a valid checkpoint exists, they compare the current authority with that checkpoint. The comparison uses the gateway name and port. If the authority changed, teardown stops before it scans listeners or changes gateway runtime resources. During full uninstall, a recorded package-managed default gateway can resolve as standalone after the service has already been removed. That narrow transition is allowed so uninstall can finish removing the remaining selected gateway registration and runtime resources.
nemoclaw stop does not scan or signal the externally supervised gateway.
Final-sandbox cleanup can stop local dashboard forwards and remove the modern local gateway registration.
It does not signal the gateway, use the legacy gateway destroy fallback, or remove its Docker volumes.
Uninstall can delete the selected sandboxes, providers, and local registration.
It keeps the externally supervised gateway process, Docker resources, and OpenShell binaries.
Registering and selecting the validated endpoint changes only the local OpenShell gateway registration used by downstream commands. It does not transfer process ownership to NemoClaw.
Fix a failure
Run nemoclaw status to read the Gateway authority mode before you inspect a service.
Fix an externally supervised gateway
Resolve an external gateway failure through the declared supervisor.
Replace <serviceName> with the serviceName value from your declaration.
For systemd-system, inspect the declared unit with the system manager:
For systemd-user, use the user manager:
Bring the supervised gateway up, leave exactly one verified process holding the configured port, and rerun nemoclaw onboard.
To hand the lifecycle back to NemoClaw, first stop and remove or disable the external supervisor and its gateway so no process remains on the configured port.
Then declare nemoclaw-managed or remove the declaration, and rerun nemoclaw onboard.
Inspect a NemoClaw-managed gateway
In nemoclaw-managed mode, no declaration names a unit.
NemoClaw uses a managed service only for the default gateway port 8080.
An owner of standalone has no service unit.
For packaged-service or a declared managed mode, the owner record does not identify the concrete service, so do not infer a unit from the install type.
Follow Reconnect after a host reboot for NemoClaw-owned service inspection, trust-scoped recovery, and standalone recovery.