PR #67881: fix(daemon): persist Discord env ref in service env

• Repository: openclaw/openclaw
• Author: lawrence3699
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67881

Description (problem / solution / changelog)

Summary

AI-assisted: Codex was used for investigation, implementation, and targeted validation. Testing: targeted local tests plus build/import-cycle checks; full repo-wide pnpm check / pnpm test were not rerun end-to-end. Session log not attached.

• Problem: Discord onboarding can store channels.discord.token as an env-backed SecretRef, but daemon install did not carry that env var into the service environment.
• Why it matters: after openclaw gateway restart under systemd/WSL2, the supervised gateway can lose the Discord bot token and fail to reconnect.
• What changed: daemon install now copies the Discord default-account env-backed SecretRef into the managed service environment when the source env var is available at install time.
• What did NOT change (scope boundary): auth-profile env refs, .env handling, non-env SecretRefs, non-Discord channel SecretRefs, and channel setup UX were left unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #67817
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: buildGatewayInstallPlan() persisted durable env vars and auth-profile env refs, but it ignored the Discord default-account env-backed SecretRef already stored at channels.discord.token.
• Missing detection / guardrail: there was no install-time bridge from the Discord default token SecretRef to the service-managed environment.
• Contributing context (if known): Discord setup docs and onboarding allow DISCORD_BOT_TOKEN with --ref-source env, which works in the invoking shell but not after a supervised restart unless the service environment also gets that value.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/commands/daemon-install-helpers.test.ts
• Scenario the test should lock in: a default Discord env-backed SecretRef should contribute DISCORD_BOT_TOKEN to the daemon install environment when that env var is present at install time.
• Why this is the smallest reliable guardrail: the failure happens in install-plan generation before any actual systemd interaction, so the helper test isolates the exact bug without needing a full supervisor environment.
• Existing test that already covers this (if any): adjacent auth-profile env-ref coverage already existed in the same file.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• openclaw gateway install / onboarding-driven daemon install now preserves a default Discord env-backed SecretRef (DISCORD_BOT_TOKEN) in the service environment when that env value is present during install.

Diagram (if applicable)

Before:
Discord onboarding stores env ref -> daemon install writes service env without DISCORD_BOT_TOKEN -> supervised restart loses token

After:
Discord onboarding stores env ref -> daemon install copies DISCORD_BOT_TOKEN into managed service env -> supervised restart keeps token

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) Yes
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:
  • The install path now persists the Discord default-account env-backed SecretRef into the managed service environment, matching the existing install-time handling of other durable env-backed credentials. The change is limited to channels.discord.token with source: "env", skips unresolved values, and reuses the existing dangerous-env filtering.

Repro + Verification

Environment

• OS: macOS (local validation), original issue reports Linux / WSL2
• Runtime/container: Node 24.14.0 / pnpm 10.32.1 in validation checkout
• Model/provider: N/A
• Integration/channel (if any): Discord daemon install path
• Relevant config (redacted): channels.discord.token = { source: "env", provider: "default", id: "DISCORD_BOT_TOKEN" }

Steps

1. Configure Discord during onboarding using DISCORD_BOT_TOKEN with --ref-source env.
2. Install or restart the gateway as a supervised daemon.
3. Inspect the install plan / service environment or restart behavior.

Expected

• The service-managed gateway still has access to DISCORD_BOT_TOKEN after restart.

Actual

• Before this change, the install plan omitted DISCORD_BOT_TOKEN, so the supervised gateway could restart without the bot token.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • Added a focused failing test for the Discord env-backed SecretRef in buildGatewayInstallPlan() and confirmed it failed before the fix.
  • Re-ran the focused test after the fix and confirmed it passed.
  • Re-ran the full daemon-install-helpers, configure.daemon, and related daemon install command test files.
  • Re-ran pnpm build, pnpm check:import-cycles, and changed-file oxlint validation.
• Edge cases checked:
  • Existing auth-profile env-ref behavior still passes unchanged.
  • Dangerous env var filtering remains in place.
  • Non-env SecretRefs remain excluded.
• What you did not verify:
  • I did not run a full interactive Discord onboarding flow under real Linux/WSL2 systemd locally.
  • I did not rerun the full repo-wide pnpm check / pnpm test suites end-to-end.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk:
  • Managed service installs now persist the Discord default token env ref when it is configured and resolvable at install time.
  • Mitigation:
    • The copy is limited to the documented default Discord token env-ref path, requires a present env value during install, and reuses the existing host-env danger filters.

Changed files