Summary

After updating OpenClaw to 2026.6.1 on macOS, a LaunchAgent-managed gateway using a secret-provider-backed environment broke because the generated gateway env wrapper was regenerated during reinstall/repair.

This is not a request to add Infisical-specific support. OpenClaw already has the right first-class mechanism via:

• openclaw gateway install --wrapper <path>
• OPENCLAW_WRAPPER

The issue is that update/install/doctor/status flows do not make it obvious when a user has modified a generated wrapper, or when CLI diagnostics are running outside the same secret-provider context as the installed gateway service.

Environment

• macOS
• LaunchAgent-managed OpenClaw gateway
• OpenClaw 2026.6.1 (2e08f0f)
• Gateway health endpoint: 127.0.0.1:18789
• Secrets provided through an external wrapper, not directly present in the interactive shell

What Happened

After running the update/reinstall flow, openclaw gateway install --force regenerated:

~/.openclaw/service-env/ai.openclaw.gateway-env-wrapper.sh

back to the plain generated wrapper behavior:

source <env-file>
exec "$@"

That overwrote local wrapper behavior that had been calling a stable secret-provider executor:

~/.openclaw/service-env/openclaw-infisical-env-exec.py

As a result:

• openclaw status printed many missing env-var warnings even though secrets had been migrated to the secret provider.
• The gateway entered a crash/spawn loop until the service wrapper/env setup was repaired.
• The interactive CLI path also remained misleading because /opt/homebrew/bin/openclaw invoked Node directly, so openclaw status bypassed the same secret-provider context used by the LaunchAgent service.

Why This Was Confusing

Generated *-env-wrapper.sh files appear to be overwritten by design, which is reasonable.

However, it is easy for operators to miss that modifying the generated wrapper is fragile. After reinstall/repair, the service and CLI can also disagree:

• The installed gateway service may have access to secrets through a wrapper.
• The interactive CLI process may not.
• openclaw status then reports missing env vars even when the intended service path has been repaired or is otherwise configured differently.

Requested Behavior

Consider one or more of the following:

1. During gateway install --force, update, or doctor repair, detect when the generated env wrapper contains non-generated custom behavior and warn before overwriting it.

2. If overwriting is intentional, explicitly recommend moving custom behavior to a stable wrapper passed through:

openclaw gateway install --wrapper <path>

or:

OPENCLAW_WRAPPER=<path>

3. Make openclaw status diagnostics clearer when required secrets may be available only through the installed gateway/service wrapper, but not through the current interactive CLI process.

4. Have doctor surface a warning when the CLI/status environment differs materially from the installed service wrapper environment.

Related Auth Profile Migration Issue

During the same update, agent runs also hit Codex app-server auth-profile validation failures around legacy profile IDs matching:

openai-codex:*

while validation expected canonical IDs like:

openai:*

This may be a separate migration-timing issue, but it appeared during the same update/repair window. It may be useful for doctor to flag legacy openai-codex:* auth-profile IDs before app-server validation rejects them, or to make that migration timing clearer.

Local Repair / Validation

After repair, the local setup was changed to:

• Use a stable wrapper outside the generated wrapper path.
• Invoke the local CLI through the same secret-provider wrapper context.
• Avoid storing secret values in generated files.

Validation after repair:

• Gateway health live on 127.0.0.1:18789
• openclaw --version returns 2026.6.1 (2e08f0f)
• openclaw status --timeout 15000 no longer reports missing env-var diagnostics
• openclaw status --deep --timeout 30000 reports Discord, iMessage, Slack, and Telegram OK