732504c8d6
Under gateway.multiplex_profiles os.environ holds the default profile's .env, so `_run_brv` building the child env from raw os.environ curated a secondary profile's turns into the DEFAULT profile's ByteRover cloud account (and prefetched the default's memories into the secondary's context). The local half was already profile-scoped (`_get_brv_cwd`). The child env now comes from `build_subprocess_env` and, under multiplex, strips the launch profile's residue and sets BRV_API_KEY only from the served profile's secret scope — a miss means no cloud key. Single-profile installs pass the process env through unchanged. Closes #108993 (report and fix direction by @jonpol01).
ByteRover Memory Provider
Persistent memory via the brv CLI — hierarchical knowledge tree with tiered retrieval (fuzzy text → LLM-driven search).
Requirements
Install the ByteRover CLI:
curl -fsSL https://byterover.dev/install.sh | sh
# or
npm install -g byterover-cli
Setup
hermes memory setup # select "byterover"
Or manually:
hermes config set memory.provider byterover
# Optional cloud sync:
echo "BRV_API_KEY=your-key" >> ~/.hermes/.env
Config
| Env Var | Required | Description |
|---|---|---|
BRV_API_KEY |
No | Cloud sync key (optional, local-first by default) |
Working directory: $HERMES_HOME/byterover/ (profile-scoped).
Tools
| Tool | Description |
|---|---|
brv_query |
Search the knowledge tree |
brv_curate |
Store facts, decisions, patterns |
brv_status |
CLI version, tree stats, sync state |