fix: env_clear() — make [agent].env a true whitelist

[chaodu-agent]

Summary

Fixes #669

Agent subprocess inherited all OAB process env vars because spawn() never called env_clear(). This means DISCORD_BOT_TOKEN, SLACK_BOT_TOKEN, and other OAB credentials were visible to the agent — a user could ask the agent to echo $DISCORD_BOT_TOKEN and get the real value back.

Before vs After

	Before	After
Agent sees OAB credentials (DISCORD_BOT_TOKEN, etc.)	✅ Yes — full inheritance	❌ No — env_clear()
Agent sees [agent].env values	✅ Yes	✅ Yes (whitelist)
Agent sees HOME, PATH	✅ Yes (inherited)	✅ Yes (explicit)
Agent sees all other host env vars	✅ Yes — everything leaked	❌ No
Warning when [agent].env is set	❌ No	✅ Log warning with key names

Changes

1. Added cmd.env_clear() in AcpConnection::spawn() — agent starts with a clean environment
2. Only HOME and PATH are passed as baseline
3. [agent].env becomes a true whitelist — only explicitly listed env vars are passed through
4. Log warning at startup when [agent].env is configured, listing the key names being exposed
5. Added security warning in config.toml.example advising OAuth login over env var API keys

Impact per backend

All supported backends use OAuth/file-based auth and work without [agent].env:

Backend	Auth method
Kiro CLI	~/.kiro/ credentials
Claude Code	claude login (OAuth)
Codex	codex login (OAuth)
Gemini CLI	gemini login (OAuth)
Copilot	gh auth login (OAuth)
OpenCode	opencode auth login

[agent].env remains available for users who need to pass custom env vars, with a startup warning about the exfiltration risk.

What was tested

• Code review: standard std::process::Command API
• Local build not possible (no C linker in this environment) — CI will verify

[github-actions]

⚠️ This PR is missing a Discord Discussion URL in the body.

All PRs must reference a prior Discord discussion to ensure community alignment before implementation.

Please edit the PR description to include a link like:

Discord Discussion URL: https://discord.com/channels/...

This PR will be automatically closed in 3 days if the link is not added.

[chaodu-agent]

Blocking finding: cmd.env("HOME", working_dir) in src/acp/connection.rs introduces a compatibility regression for configurations where working_dir is only a workspace path, not the agent home directory. On main, working_dir is documented as the agent working directory in README.md, and its default remains /tmp in src/config.rs. Before this PR, child processes inherited the real HOME, so locally authenticated CLIs could still find ~/.codex, ~/.claude, ~/.config/gh, etc. After this change, any config that leaves working_dir = "/tmp" (or points it somewhere other than the auth home) will lose access to those existing credentials and can fail even though no secrets are being leaked anymore. env_clear() itself looks right; the risky part is repurposing working_dir as HOME.

[chaodu-agent]

Re-review on latest head (a6ceeee, de41c50): the Windows baseline env additions look good, but my earlier blocking concern is still unresolved because the runtime behavior did not change. HOME is still forcibly set to working_dir; the new comment clarifies that this is intentional, but it does not remove the compatibility regression for configs where working_dir is only a workspace path or is left at the default /tmp. So my verdict is unchanged: env_clear() is good, Windows baseline vars are good, but repurposing working_dir as HOME still breaks previously working auth setups unless users also discover and override it via [agent].env.

[chaodu-agent]

Re-review on latest head (51bc256): this resolves my previous blocker. The child process now preserves the real HOME/USERPROFILE from the parent environment, falling back to working_dir only when those vars are unset, so existing OAuth/auth file lookup paths (~/.codex, ~/.claude, ~/.config/gh, etc.) keep working. env_clear() still provides the intended credential-leakage fix, and the Windows baseline env additions remain correct. LGTM from my side.