# Claude-Profile Gotchas

## Context-loader path assumes sibling location

The original `claude-profile` script set `CONTEXT_LOADER="${SCRIPT_DIR}/context-load"`, but `context-load` lives in `claude-foundations/scripts/`, not as a sibling of `claude-profile`. Fix: use `command -v context-load` (it's symlinked into `~/sbin`) as the primary lookup, with the sibling path as a fallback for testing isolation. Use `readlink -f "$0"` so the lookup works when `claude-profile` itself is symlinked.

## Verify `claude --model` support before designing workarounds

Before designing workarounds for harness limitations (per-driver profile dirs, settings.json rewriting), verify the actual capability. A 30-second check via the `claude-code-guide` agent confirmed `claude --model` is session-scoped and accepts both aliases (`sonnet`, `opus`) and full model IDs. This prevented building 3 unnecessary workarounds.

## Dead env vars accumulate in `active-mode.env` if not audited

Symptom: `CLAUDE_TIME_HORIZON` was written to `active-mode.env` and asked interactively at every launch, but no downstream tool ever consumed it. `CLAUDE_PROVIDER` was only read by the statusline for non-Anthropic short-name display — redundant once provider was promoted to a per-profile concern.

Fix: when changing an interactive prompt or a launcher field, grep all consumers (`grep -r CLAUDE_TIME_HORIZON ~`) before keeping it. Removed both vars entirely; updated `custom-claude-skills/skills/switch-mode/SKILL.md` to drop them from its `active-mode.env` template, and `~/.claude/status/statusline.sh` to stop parsing `CLAUDE_PROVIDER`.