# Start from a clean state: no profile dir, no main creds
rm -rf ~/.openclaw-testcase
rm -rf ~/.openclaw/credentials/whatsapp/default

# Create an isolated profile
openclaw --profile testcase onboard \
  --non-interactive --accept-risk --flow quickstart \
  --workspace ~/.openclaw-testcase/workspace \
  --auth-choice openai-api-key --openai-api-key sk-... \
  --gateway-port 18900 --gateway-bind loopback \
  --gateway-auth token --skip-channels --skip-health

# Install and start as a systemd service
openclaw --profile testcase gateway install
openclaw --profile testcase gateway start

# Attempt WhatsApp login via the gateway
openclaw --profile testcase gateway call web.login.start \
  --params '{"accountId":"default"}' --json

# Observe where creds.json landed
find ~/.openclaw-testcase/credentials ~/.openclaw/credentials -name creds.json -printf '%p %s %TY-%Tm-%Td %TT\n' 2>/dev/null

$ cat /proc/$(pgrep openclaw-gatewa)/environ | tr '\0' '\n' | grep OPENCLAW
OPENCLAW_STATE_DIR=/home/openclaw/.openclaw-sec-hilton-junior-bee9f2c4
OPENCLAW_CONFIG_PATH=/home/openclaw/.openclaw-sec-hilton-junior-bee9f2c4/openclaw.json
OPENCLAW_PROFILE=sec-hilton-junior-bee9f2c4
...

## Where the resolution likely goes wrong

Initial investigation points at `extensions/whatsapp/src/accounts.ts:47`:


export function listWhatsAppAuthDirs(cfg: OpenClawConfig): string[] {
  const oauthDir = resolveOAuthDir();   // ← no env arg passed
  ...
}


`resolveOAuthDir()` in `src/config/paths.ts:236` has a default of `process.env`, but if this function is imported and the result memoized at module-load time (before the profile's `OPENCLAW_STATE_DIR` is applied to `process.env` by `applyCliProfileEnv()` at `src/cli/profile.ts:110`), the resolved path will be wrong.

A similar pattern exists in `resolveDefaultAuthDir()` and `resolveLegacyAuthDir()` in the same file:


function resolveDefaultAuthDir(accountId: string): string {
  return path.join(resolveOAuthDir(), "whatsapp", normalizeAccountId(accountId));
}

function resolveLegacyAuthDir(): string {
  return resolveOAuthDir();
}


These do not accept a config/context argument and rely entirely on the ambient environment at call time.

## Workaround

Setting `OPENCLAW_OAUTH_DIR` explicitly in the profile's systemd unit file forces the path regardless of module init order:


[Service]
Environment=OPENCLAW_STATE_DIR=/home/openclaw/.openclaw-<profile>
Environment=OPENCLAW_OAUTH_DIR=/home/openclaw/.openclaw-<profile>/credentials
Environment=OPENCLAW_CONFIG_PATH=/home/openclaw/.openclaw-<profile>/openclaw.json


After `systemctl --user daemon-reload` and restart, `creds.json` lands in the profile dir and stays isolated. Verified: the WhatsApp session pairs cleanly via `openclaw --profile <profile> channels login` and all 800+ Baileys state files end up under `~/.openclaw-<profile>/credentials/whatsapp/default/`.

## Suggested fix

1. **Pass the config/env explicitly.** `listWhatsAppAuthDirs(cfg)`, `resolveDefaultAuthDir(accountId)`, and `resolveLegacyAuthDir()` should accept an explicit `env` or `stateDir` argument and thread it through to `resolveOAuthDir()`, instead of relying on `process.env` at the moment of the (possibly lazy) call.
2. **Avoid top-level caching.** Any module that does `const OAUTH_DIR = resolveOAuthDir()` at load time is a latent isolation bug under `--profile`. These should be deferred or invoked with the runtime env.
3. **Doctor check.** `openclaw --profile <name> doctor` should warn when it detects `credsPath` outside the profile's state dir, pointing at the workaround above until the fix lands.
4. **Consider documenting `OPENCLAW_OAUTH_DIR`** as a supported isolation mechanism so SaaS operators don't have to infer it from source.