Bug type

Behavior bug (gateway crash-loops on next start; user customizations silently lost)

Summary

Every successful openclaw update regenerates ~/.config/systemd/user/openclaw-gateway.service and silently strips any user-added EnvironmentFile= or Environment= directives that aren't part of OpenClaw's managed default set. Gateway then crash-loops on next start because referenced env vars aren't loaded.

Confirmed across multiple version bumps:

• 2026.4.2 (initial bite, documented locally)
• 2026.4.5
• 2026.4.12 (reproduced today, see below)

Steps to reproduce

1. Working OpenClaw with secrets in ~/.openclaw/workspace/.env (e.g. KIMI_API_KEY=...)
2. Add EnvironmentFile=/home/<user>/.openclaw/workspace/.env to ~/.config/systemd/user/openclaw-gateway.service so the env is loaded at service start
3. openclaw update --yes to next version
4. Update completes, gateway restart attempts, gateway crash-loops with SecretRefResolutionError: Environment variable "KIMI_API_KEY" is missing or empty
5. Inspect unit file → EnvironmentFile= is gone

Expected behavior

openclaw update either:

• Preserves user-added directives in the regenerated unit, OR
• Writes OpenClaw-managed directives (the ones tracked by OPENCLAW_SERVICE_MANAGED_ENV_KEYS) to a separate drop-in like ~/.config/systemd/user/openclaw-gateway.service.d/openclaw-managed.conf, leaving the main unit user-owned after first install

The drop-in approach mirrors how version.conf-style overrides already work, and it cleanly solves the related token-rebake symptom in #66219 (re-embeds tokens) and #54521 (inlines .env secrets).

Actual behavior

Main unit is regenerated wholesale on each upgrade. Anything not in OpenClaw's managed-defaults template is lost without warning. The OPENCLAW_SERVICE_MANAGED_ENV_KEYS mechanism almost solves this — it tracks what OpenClaw owns — but the regeneration still rewrites the entire file rather than touching only the managed lines.

Impact

• Hard-to-debug failure mode — the SecretRefResolutionError doesn't point at "your unit was rewritten 2 minutes ago"; it looks like a fresh secrets misconfiguration
• Tooling can't fully prevent it — even users who wrap openclaw update in a snapshot+restore script (which I do) hit a window where the gateway crash-loops between regeneration and the restore step
• Recurs forever — every minor upgrade re-bites users who depend on EnvironmentFile= or extra Environment= lines (and EnvironmentFile= is the recommended pattern per the discussion in [Bug]: Linux Secrets Incontinuity - gateway install should use ~/.openclaw/.env as EnvironmentFile (or symlink) #53926)

Reproduction artifacts (today, 2026.4.12)

Crash log on second restart attempt:

```
[secrets] [SECRETS_RELOADER_DEGRADED] SecretRefResolutionError: Environment variable "KIMI_API_KEY" is missing or empty.
Gateway failed to start: Error: Startup failed: required secrets are unavailable.
```

Pre-upgrade unit had `EnvironmentFile=/home//.openclaw/workspace/.env` after the `Environment=GEMINI_API_KEY=…` line. Post-upgrade unit had no `EnvironmentFile=` at all.

Planned fix (PR incoming)

I'll send a PR for the drop-in approach: move OpenClaw-managed env into `openclaw-gateway.service.d/openclaw-managed.conf`, write that file from `openclaw update` and `gateway install`, and stop touching the main unit after first install. The drop-in approach mirrors the existing `version.conf`-style overrides, composes cleanly with systemd's override semantics, and survives wholesale regeneration without needing extra tracking beyond what `OPENCLAW_SERVICE_MANAGED_ENV_KEYS` already does.

Will test on a clean LXC build environment (real systemd, real upgrade flow) before opening — covering fresh install, in-place upgrade from a unit that already has inline managed env, downgrade safety, and the crash-loop repro above.

If you'd prefer a different shape (e.g. preserve-and-merge the existing unit instead of moving managed keys to a drop-in), happy to redirect before I write code. Posting the issue now to surface the design choice before I commit to an approach.

Related

• openclaw update removes systemd service file and does not recreate it #41914 (update removes unit entirely — different symptom, related lifecycle bug)
• [Bug]: openclaw doctor --repair Re-embeds Sensitive Tokens in Systemd Service #66219 (doctor --repair re-embeds sensitive tokens — same root cause: unit regeneration loses user state)
• gateway install inlines .env secrets into systemd unit while doctor flags inline OPENCLAW_GATEWAY_TOKEN as stale #54521, gateway install --force keeps stale embedded OPENCLAW_GATEWAY_TOKEN in systemd unit #57104 (inlining `.env` secrets / stale tokens in unit)
• [Bug]: Linux Secrets Incontinuity - gateway install should use ~/.openclaw/.env as EnvironmentFile (or symlink) #53926 (install-time EnvironmentFile path mismatch)
• openclaw doctor --fix rewrites macOS LaunchAgent plist, drops user-defined EnvironmentVariables #45163 (same pattern on macOS LaunchAgent)

Environment

• OS: Ubuntu 24.04 Desktop, kernel 6.17
• Service manager: systemd (user-level)
• OpenClaw: 2026.4.12 (0362f21)
• Install: hackable source-linked (`/usr/lib/node_modules/openclaw` → `~/openclaw`, gateway `ExecStart` runs `dist/index.js` directly)
• Confirmed across multiple minor upgrades (.2, .5, .12)