includes check can match commented-out entries

existing.includes("NODE_EXTRA_CA_CERTS") will match a commented-out line such as # NODE_EXTRA_CA_CERTS=/old/path, silently preventing the active entry from ever being written. Consider anchoring to only uncommented occurrences:

This is a comment left during a code review.
Path: src/cli/daemon-cli/install.ts
Line: 161

Comment:
**`includes` check can match commented-out entries**

`existing.includes("NODE_EXTRA_CA_CERTS")` will match a commented-out line such as `# NODE_EXTRA_CA_CERTS=/old/path`, silently preventing the active entry from ever being written. Consider anchoring to only uncommented occurrences:

```suggestion
    if (/^NODE_EXTRA_CA_CERTS=/m.test(existing)) {
```

How can I resolve this? If you propose a fix, please make it concise.

Hardcoded process.platform / process.execPath breaks testability

ensureNvmCaCertsInDotEnv reads process.platform and process.execPath directly, while both buildServiceEnvironment and buildNodeServiceEnvironment accept execPath as an injectable parameter for exactly this reason. The function is not covered by unit tests because of this, unlike every other piece of nvm-detection logic in this PR.

Consider threading platform and execPath through params (or a separate argument) so the function can be tested the same way the service-env builders are:

function ensureNvmCaCertsInDotEnv(params: {
  env: Record<string, string | undefined>;
  json: boolean;
  warnings: string[];
  platform?: NodeJS.Platform;   // defaults to process.platform
  execPath?: string;            // defaults to process.execPath
}): void {
  const platform = params.platform ?? process.platform;
  const execPath = params.execPath ?? process.execPath;
  if (platform !== "linux" || !isNvmNode(params.env, execPath)) {

This is a comment left during a code review.
Path: src/cli/daemon-cli/install.ts
Line: 146-148

Comment:
**Hardcoded `process.platform` / `process.execPath` breaks testability**

`ensureNvmCaCertsInDotEnv` reads `process.platform` and `process.execPath` directly, while both `buildServiceEnvironment` and `buildNodeServiceEnvironment` accept `execPath` as an injectable parameter for exactly this reason. The function is not covered by unit tests because of this, unlike every other piece of nvm-detection logic in this PR.

Consider threading `platform` and `execPath` through `params` (or a separate argument) so the function can be tested the same way the service-env builders are:

```typescript
function ensureNvmCaCertsInDotEnv(params: {
  env: Record<string, string | undefined>;
  json: boolean;
  warnings: string[];
  platform?: NodeJS.Platform;   // defaults to process.platform
  execPath?: string;            // defaults to process.execPath
}): void {
  const platform = params.platform ?? process.platform;
  const execPath = params.execPath ?? process.execPath;
  if (platform !== "linux" || !isNvmNode(params.env, execPath)) {
```

How can I resolve this? If you propose a fix, please make it concise.

Write NODE_EXTRA_CA_CERTS to the active dotenv state dir

ensureNvmCaCertsInDotEnv writes to resolveGatewayStateDir, but CLI dotenv loading uses resolveStateDir (loadCliDotEnv) to pick the active state directory, including legacy dirs (~/.clawdbot/~/.moldbot) or CLAWDBOT_STATE_DIR. For users still on a legacy state dir, this new write goes to ~/.openclaw/.env while openclaw gateway run reads a different .env, so the intended TLS fix is silently not applied on manual runs.

Useful? React with 👍 / 👎.

Write NODE_EXTRA_CA_CERTS to the CLI-active dotenv path

ensureNvmCaCertsInDotEnv writes into resolveGatewayStateDir, but CLI startup still loads .env from resolveStateDir (src/cli/dotenv.ts), which can resolve to a different directory (legacy state dirs and env-only profile setups). That means the new NODE_EXTRA_CA_CERTS entry can be written to a file that openclaw gateway run never reads, so the TLS fix is silently skipped for affected installs. Fresh evidence: src/cli/run-main.ts calls loadCliDotEnv directly, and resolveStateDir does not use OPENCLAW_PROFILE unless OPENCLAW_STATE_DIR is explicitly set.

Useful? React with 👍 / 👎.

Detect stale nvm services from the installed command

When openclaw gateway install is run on an already-installed service, this refresh check computes the expected CA bundle from the current CLI process (process.execPath and params.env) instead of the executable that the service is actually configured to run. That misses the main upgrade case this patch is trying to fix: an older gateway service still points at ~/.nvm/.../node, but the user now invokes openclaw gateway install from a system Node or Bun shell. In that scenario resolveAutoNodeExtraCaCerts(...) returns undefined, the reinstall is skipped, and the existing nvm-backed daemon keeps failing TLS. readCommand() already returns programArguments, so the check should key off currentCommand.programArguments[0] rather than the installer's runtime.

Useful? React with 👍 / 👎.

Preserve custom NODE_EXTRA_CA_CERTS on installed services

If an existing gateway service intentionally sets NODE_EXTRA_CA_CERTS to a non-default bundle (for example a corporate CA file), this check still treats the service as stale and forces a reinstall because it only accepts the auto-detected system path. In that scenario a plain openclaw gateway install stops being a no-op: buildGatewayInstallPlan rebuilds the service environment from the current shell/config, so the service-local CA bundle is dropped and TLS can break after the refresh.

Useful? React with 👍 / 👎.

Pass the chosen runtime path into Linux CA auto-detection

This new Linux branch only works when callers supply execPath; otherwise resolveAutoNodeExtraCaCerts falls back to the installer's process.execPath. buildGatewayInstallPlan and buildNodeInstallPlan still call build*ServiceEnvironment without that argument, so any flow that targets an nvm-managed Node via nodePath while the installer itself runs under Bun or a system Node will generate a service whose programArguments[0] points at ~/.nvm/.../node but whose environment omits NODE_EXTRA_CA_CERTS, leaving the TLS failure unchanged.

Useful? React with 👍 / 👎.