openclaw - ✅(Solved) Fix gateway install silently drops custom PATH/env vars from LaunchAgent plist on macOS [1 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63040Fetched 2026-04-09 07:59:12
View on GitHub
Comments
2
Participants
2
Timeline
3
Reactions
0
Author
Timeline (top)
commented ×2cross-referenced ×1

Error Message

No warning, no error, and no log entry indicated that PATH had changed. The agent simply reported tools as not found.

  • Warn the user explicitly that PATH and other environment variables in the plist will be reset, and document how to re-add custom entries after install, or

Fix Action

Fixed

PR fix notes

PR #63136: fix(daemon): preserve safe env vars on gateway reinstall

Description (problem / solution / changelog)

Closes #63040

Summary

  • preserve safe custom service environment variables when openclaw gateway install --force rewrites the LaunchAgent plist
  • merge existing PATH entries with the regenerated service PATH instead of silently replacing them
  • add tests for both install-plan preservation and daemon CLI reinstall flow

Root cause

runDaemonInstall() read the existing LaunchAgent environment, but buildGatewayInstallPlan() rebuilt the final service environment from scratch. That meant safe custom variables from the existing plist, including custom PATH segments and vars like GOPATH / GOBIN, were dropped on reinstall.

Test plan

  • node scripts/run-vitest.mjs run --config vitest.commands.config.ts src/commands/daemon-install-helpers.test.ts
  • did not run src/cli/daemon-cli.coverage.test.ts successfully in this environment because it currently fails on a missing repo dependency: @mariozechner/pi-coding-agent

Changed files

  • src/cli/daemon-cli.coverage.test.ts (modified, +38/-3)
  • src/cli/daemon-cli/install.ts (modified, +1/-0)
  • src/commands/daemon-install-helpers.test.ts (modified, +31/-0)
  • src/commands/daemon-install-helpers.ts (modified, +64/-0)
RAW_BUFFERClick to expand / collapse

What happened?

The openclaw gateway install command (and by extension any auto-install triggered by an OpenClaw update) writes a new LaunchAgent plist that does not preserve the existing PATH from the previous plist. On macOS, LaunchAgents do not source ~/.zshrc or any shell profile — they inherit only the environment variables explicitly embedded in the plist at install time. If the user's shell profile sets custom environment variables such as GOPATH, GOBIN, or additional PATH entries, those are silently dropped every time openclaw gateway install runs.

In our case, GOPATH and GOBIN were configured as ~/.local/gopath and ~/.local/gopath/bin. After the 2026.4.5 update ran gateway install, those exports were no longer present in the gateway's environment. Any skill or tool installed via go install — in our case blogwatcher — became silently unavailable to the agent even though the binary existed on disk and which blogwatcher worked correctly in an interactive shell.

No warning, no error, and no log entry indicated that PATH had changed. The agent simply reported tools as not found.

A secondary consequence: the update also dropped the GOPATH/GOBIN exports from ~/.zshrc itself (or they were never re-added after a previous update). This caused go install to fall back to the default ~/go/bin location instead of the configured ~/.local/gopath/bin, creating a split-brain state where reinstalling a binary placed it in the wrong directory.

Steps to reproduce

  1. Install OpenClaw on macOS with a user account that has custom shell environment variables set in ~/.zshrc — specifically GOPATH, GOBIN, or any PATH additions outside the default Homebrew/system locations.
  2. Install a Go-based skill binary via go install (for example blogwatcher). Confirm the agent can find and run it.
  3. Run openclaw update or manually run openclaw gateway install (or openclaw gateway install --force).
  4. Send any agent message that invokes the Go-based skill tool.
  5. Observe: the agent reports the tool as not found. launchctl getenv PATH for the gateway process no longer contains the Go bin directory. The binary still exists on disk.

Expected behavior

openclaw gateway install should either:

  • Read the existing plist before overwriting it and preserve any EnvironmentVariables entries that it did not itself write, or
  • Warn the user explicitly that PATH and other environment variables in the plist will be reset, and document how to re-add custom entries after install, or
  • Source ~/.zshrc or ~/.zprofile at install time to capture the user's full shell environment into the new plist.

The current behaviour silently degrades the agent's tool availability after every update with no indication to the user that anything has changed.

Version

2026.4.5 (3e72c03)

extent analysis

TL;DR

The openclaw gateway install command should be modified to preserve existing environment variables from the previous LaunchAgent plist or warn the user about potential changes to the PATH.

Guidance

  • Verify the current LaunchAgent plist for the gateway process using launchctl list and check the EnvironmentVariables entries to confirm the issue.
  • Manually re-add the custom GOPATH and GOBIN environment variables to the new plist after running openclaw gateway install to mitigate the issue temporarily.
  • Consider modifying the openclaw gateway install command to read the existing plist and preserve any EnvironmentVariables entries that it did not itself write.
  • Test the fix by reinstalling the Go-based skill binary via go install and sending an agent message that invokes the tool to ensure it is found and runs correctly.

Example

No code snippet is provided as the issue does not imply a specific code change, but rather a modification to the openclaw gateway install command's behavior.

Notes

The issue is specific to macOS and LaunchAgents, which do not source shell profiles. The fix should ensure that custom environment variables are preserved or the user is warned about potential changes to the PATH.

Recommendation

Apply a workaround by manually re-adding custom environment variables to the new plist after running openclaw gateway install, as modifying the command's behavior may require changes to the OpenClaw codebase.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

openclaw gateway install should either:

  • Read the existing plist before overwriting it and preserve any EnvironmentVariables entries that it did not itself write, or
  • Warn the user explicitly that PATH and other environment variables in the plist will be reset, and document how to re-add custom entries after install, or
  • Source ~/.zshrc or ~/.zprofile at install time to capture the user's full shell environment into the new plist.

The current behaviour silently degrades the agent's tool availability after every update with no indication to the user that anything has changed.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING