CA bundle path not validated before use on non-Debian Linux

/etc/ssl/certs/ca-certificates.crt is the correct bundle location on Debian/Ubuntu/Alpine, but it does not exist on RHEL/Fedora/CentOS (where it lives at /etc/pki/tls/certs/ca-bundle.crt) or openSUSE (/etc/ssl/ca-bundle.pem). Assigning NODE_EXTRA_CA_CERTS to a path that does not exist on disk causes Node.js to throw an ENOENT error when any TLS connection is attempted — making things actively worse for users on those distros (all HTTPS calls fail rather than just returning incorrect CA validation). The same non-existent path is written to .env in install.ts.

A safer approach is to resolve the bundle at runtime by probing the known paths, or at minimum, skip setting NODE_EXTRA_CA_CERTS when the file is absent:

This is a comment left during a code review.
Path: src/daemon/service-env.ts
Line: 349-355

Comment:
**CA bundle path not validated before use on non-Debian Linux**

`/etc/ssl/certs/ca-certificates.crt` is the correct bundle location on Debian/Ubuntu/Alpine, but it does not exist on RHEL/Fedora/CentOS (where it lives at `/etc/pki/tls/certs/ca-bundle.crt`) or openSUSE (`/etc/ssl/ca-bundle.pem`). Assigning `NODE_EXTRA_CA_CERTS` to a path that does not exist on disk causes Node.js to throw an ENOENT error when any TLS connection is attempted — making things actively *worse* for users on those distros (all HTTPS calls fail rather than just returning incorrect CA validation). The same non-existent path is written to `.env` in `install.ts`.

A safer approach is to resolve the bundle at runtime by probing the known paths, or at minimum, skip setting `NODE_EXTRA_CA_CERTS` when the file is absent:

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

Fixed in 66143c0: resolveLinuxSystemCaBundle() now probes /etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu/Alpine), /etc/pki/tls/certs/ca-bundle.crt (RHEL/Fedora/CentOS), and /etc/ssl/ca-bundle.pem (openSUSE). Returns undefined when none exists, so we never set NODE_EXTRA_CA_CERTS to a missing path.

isNvmNode called without execPath here but with it in install.ts

In resolveSharedServiceEnvironmentFields, isNvmNode(env) only checks the NVM_DIR environment variable. In install.ts, the same detection uses isNvmNode(params.env, process.execPath), which also inspects the binary path. If a user sources nvm without NVM_DIR being exported (uncommon, but valid), the systemd service environment will not receive NODE_EXTRA_CA_CERTS even though install.ts will have written it to .env. Passing process.execPath here as well would keep the two codepaths consistent.

This is a comment left during a code review.
Path: src/daemon/service-env.ts
Line: 353

Comment:
**`isNvmNode` called without `execPath` here but with it in `install.ts`**

In `resolveSharedServiceEnvironmentFields`, `isNvmNode(env)` only checks the `NVM_DIR` environment variable. In `install.ts`, the same detection uses `isNvmNode(params.env, process.execPath)`, which also inspects the binary path. If a user sources nvm without `NVM_DIR` being exported (uncommon, but valid), the systemd service environment will not receive `NODE_EXTRA_CA_CERTS` even though `install.ts` will have written it to `.env`. Passing `process.execPath` here as well would keep the two codepaths consistent.

```suggestion
    : platform === "linux" && isNvmNode(env, process.execPath)
```

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

Intentionally kept env-only detection in resolveSharedServiceEnvironmentFields — this function builds env for a different process context (the systemd service), so process.execPath of the current process isn't representative. The service env builder should be conservative and rely on NVM_DIR in the passed env dict.

The install flow uses isNvmNode(params.env, process.execPath) because it runs in the actual nvm context and writes to .env (which dotenv loads at runtime). The .env backfill now also runs on the already-installed path (66143c0), covering users who don't pass --force.

Use execPath fallback in Linux nvm detection

resolveSharedServiceEnvironmentFields only calls isNvmNode(env), so it never uses the new execPath-based detection path. In environments where NVM_DIR is not exported but the CLI is still running from ~/.nvm/.../node (common with non-interactive shells), buildServiceEnvironment will not set NODE_EXTRA_CA_CERTS, and the installed gateway service can still hit the same TLS fetch failed behavior this change is trying to fix.

Useful? React with 👍 / 👎.

See reply on the greptile thread above — intentionally env-only in the service env builder. The install flow uses both env + execPath and now also runs on the already-installed path.

Backfill .env even when install reports already-installed

The nvm .env backfill is executed only at the end of the successful install path, but runDaemonInstall returns early on the default already-installed path. That means users upgrading to this fix (who typically already have the service installed) can run openclaw gateway install and still never get NODE_EXTRA_CA_CERTS written to ~/.openclaw/.env, leaving manual gateway run sessions unfixed unless they discover they need --force.

Useful? React with 👍 / 👎.

Fixed in 66143c0: ensureNvmCaCertsInDotEnv now runs on the already-installed early-return path too, so users upgrading get the .env entry without needing --force.

Pass execPath when detecting nvm for service env defaults

resolveSharedServiceEnvironmentFields only calls isNvmNode(env), so the new execPath fallback path is never used when building daemon service environments. On Linux hosts where NVM_DIR is not exported but the CLI is running from ~/.nvm/.../node (a common non-interactive shell setup), NODE_EXTRA_CA_CERTS is omitted from the installed service environment, so TLS fetch failed behavior can persist even after reinstalling.

Useful? React with 👍 / 👎.

Fixed in 31dee69: resolveSharedServiceEnvironmentFields now accepts an injectable execPath parameter (defaults to process.execPath). Both buildServiceEnvironment and buildNodeServiceEnvironment pass it through, so nvm is detected via both NVM_DIR env var and exec path. Tests pass explicit execPath values for determinism.

Detect nvm from daemon runtime path, not installer runtime

The Linux CA fallback now keys off process.execPath, which is the CLI runtime, not necessarily the daemon runtime selected for install. In supported flows where install runs under Bun but the daemon is installed with --runtime node, resolveGatewayProgramArguments can still choose an nvm Node binary while this check sees Bun and returns false, so NODE_EXTRA_CA_CERTS is omitted and the TLS fetch failed issue persists. Fresh evidence: both buildGatewayInstallPlan and buildNodeInstallPlan call build*ServiceEnvironment without providing the resolved node path, so this branch always falls back to the installer process path.

Useful? React with 👍 / 👎.

Valid edge case but very unlikely in practice: a user running install under Bun while the daemon uses nvm Node would need NVM_DIR set (or nvm sourced) to resolve the node binary. In that scenario NVM_DIR in the env dict would already trigger detection.

The resolved daemon runtime binary path isn't available when building the service environment since it's computed separately in resolveGatewayProgramArguments. Threading it back would add significant coupling for a marginal edge case. The .env backfill covers the common path. Noting as a potential follow-up if the edge case surfaces in practice.

Detect nvm using the daemon runtime path

Use the daemon’s resolved Node binary path here instead of defaulting to process.execPath, otherwise Linux installs can miss NODE_EXTRA_CA_CERTS when the installer runtime differs from the service runtime. Fresh evidence: if resolvePreferredNodePath cannot return a supported system node (src/daemon/runtime-paths.ts:181-185), resolveGatewayProgramArguments falls back to PATH lookup (src/daemon/program-args.ts:171-174), which can pick ~/.nvm/.../node even when process.execPath is non-nvm; this branch then returns undefined and TLS failures persist for the installed daemon.

Useful? React with 👍 / 👎.