[Bug]: OMP agent integration ignores XDG mode — managed extensions written to `~/.omp/agent` and daemon spawns fragment data state without XDG_DATA_HOME
- Dominant language
- TypeScript
- Stars
- 71.3k
- Forks
- 4.7k
- Avg merge
- 14h 54m
- Merged PRs (30d)
- 520
Description
### Operating system
macOS
### Orca version
_No response_
### Details
## Summary
Orca's OMP (oh-my-pi) integration hardcodes the agent dir to `~/.omp/agent` and
has no awareness of OMP's XDG mode. When OMP runs under Orca in an environment
without `XDG_DATA_HOME`, OMP resolves its root as:
- `$XDG_CONFIG_HOME/omp` if `XDG_CONFIG_HOME` is set (common for GUI-spawned
processes), else `~/.omp`
- agent dir = `/agent`
Meanwhile a login shell with `XDG_DATA_HOME` set — and `$XDG_DATA_HOME/omp`
already existing — redirects OMP's agent/data state to `$XDG_DATA_HOME/omp`.
Result: the same user gets **three disjoint OMP homes** depending on which
process spawned OMP:
| Spawner | OMP agent dir used |
|---|---|
| Login shell (zprofile sets XDG vars) | `~/.local/share/omp` ✔ |
| Orca daemon / non-login spawn (`XDG_CONFIG_HOME` set, `XDG_DATA_HOME` unset) | `~/.config/omp/agent` ✘ |
| Spawn with no XDG vars at all | `~/.omp/agent` ✘ |
OMP's own rule (from oh-my-pi docs, `environment-variables.md` §6):
`XDG_DATA_HOME` / `XDG_STATE_HOME` / `XDG_CACHE_HOME` *"redirect corresponding
OMP paths only when the target omp root (or named-profile root) already
exists"*.
## Symptoms
Observed on macOS 26 (arm64), Orca 1.4.198, OMP 18.1.17, OMP used in XDG mode
(`~/.local/share/omp` as the canonical data dir). Still present in `main` as of
v1.4.200.
- OMP sessions, `agent.db`, `history.db`, `models.db`, skills, and extensions
written under `~/.config/omp/agent/` — invisible to OMP instances started
from login shells, and vice versa (missing history, missing sessions,
"config reset" symptoms).
- Same divergence with `~/.omp/agent` for spawns that inherit no XDG vars at
all (e.g. Electron daemon children).
- Orca's managed OMP extensions (`orca-agent-status.ts`,
`orca-prefill.ts`, `orca-titlebar-spinner.ts`) are materialized into
`~/.omp/agent/extensions/` and injected via `ORCA_OMP_STATUS_EXTENSION`,
reinforcing the hardcoded non-XDG home.
- Live processes verified via `lsof`: login-shell OMP instances hold only
`~/.local/share/omp` databases; Orca-spawned instances wrote the other two
trees. Merging the divergence required manually copying sessions, merging
SQLite history rows, and moving skills.
## Root cause
`src/main/pi/titlebar-extension-service.ts` hardcodes the per-agent home and
never consults XDG:
```ts
const AGENT_HOME_DIR_NAME: Record = {
pi: '.pi',
omp: '.omp',
'prime-agent': '.prime'
}
function getDefaultPiAgentDir(kind: PiAgentKind): string {
return join(homedir(), AGENT_HOME_DIR_NAME[kind], PI_AGENT_SUBDIR) // → ~/.omp/agent
}
```
`ORCA_OMP_SOURCE_AGENT_DIR` is later populated from `installed.sourceAgentDir`,
which traces back to this default — so the override that is supposed to be the
escape hatch is itself seeded from the hardcoded path.
Nothing in `src/main/ipc/pty/host-env/` (the env-routing layer) considers
`XDG_DATA_HOME` when deriving the OMP agent dir or when deciding where to
materialize managed extensions.
## Existing workaround
Setting `ORCA_OMP_SOURCE_AGENT_DIR=$XDG_DATA_HOME/omp` in the spawning
environment (e.g. via `launchctl setenv` for GUI apps) makes Orca materialize
its managed extensions into `~/.local/share/omp/extensions/` and route the
status-extension flag there. This works — `ORCA_OMP_SOURCE_AGENT_DIR` is
Orca's first-class override (see #5719's expected-behavior spec: *"if
`ORCA_OMP_SOURCE_AGENT_DIR` exists, OMP should use it"*) — but it must be
injected into every GUI-spawned process, which is fragile on macOS
(`launchctl setenv` doesn't survive reboot without a LaunchAgent, and daemons
already running keep their old env).
## Expected behavior
Orca's OMP env routing should mirror OMP's own resolution: when
`XDG_DATA_HOME` is set and `$XDG_DATA_HOME/omp` exists, Orca should treat
`$XDG_DATA_HOME/omp` as the OMP agent dir — for `ORCA_OMP_STATUS_EXTENSION`
materialization, `ORCA_OMP_SOURCE_AGENT_DIR` derivation, and any overlay
routing — instead of the hardcoded `~/.omp/agent`.
**This should not reintroduce cross-agent fallback.** The comment above
`AGENT_HOME_DIR_NAME` notes that the per-agent hardcoding is deliberate: the
managed-extension target must be chosen by which agent is being launched, not
by whichever `~/./agent` dir happens to exist on disk first, or Pi and
OMP silently shadow each other's user extensions when both are installed. The
fix proposed here preserves that invariant. Resolution stays keyed to
`PiAgentKind` throughout — for `kind`, check `$XDG_DATA_HOME/` and
fall back to `~/.(kind)/agent` — so the existence probe is never shared
across agent kinds and can never select another agent's home. XDG only changes
*where a given agent's* home is looked for, not *which agent's* home is used.
Note for sequencing: this touches the same materialization path as the open
PR #11276 (`fix(omp): load prefill extension so Linear drafts reach OMP`), so
the two will likely want ordering.
## Environment
- Orca: 1.4.198 (macOS, arm64); behavior unchanged through v1.4.200
- OMP: 18.1.17 (`~/.local/bin/omp`, XDG mode with `~/.local/share/omp` as
data root)
- Verified with `ps eww` / `lsof` / sandboxed OMP resolution tests; bundle
inspection of `app.asar` and the public repo source.
## Related
- #5719 — OMP inheriting Pi's overlay config home (fixed); established the
`ORCA_OMP_SOURCE_AGENT_DIR` routing this issue builds on.
- #7091 — WSL: OMP status env injected but the managed extension never loads.
Same materialization step resolving to the wrong place for a different
reason.
- #10198 — `fix(pty): do not create unused Pi/OMP home dirs on bare shells`.
This path was deliberately revisited after OMP's XDG rule already existed,
and XDG awareness still wasn't added — which is why a one-off patch here
keeps missing the general case.
- #9186 / #9192 — the OpenCode analog: Orca ignores the default
`~/.config/opencode` when `OPENCODE_CONFIG_DIR` is unset. Same class of
per-agent env-routing gap, still open.
- Earlier, pre-XDG OMP config-home divergence bugs: #5563, #5521, #5675.
Contributor guide
Research direction
Start in src/main/pi/titlebar-extension-service.ts, especially getDefaultPiAgentDir and the PiAgentKind mapping, then trace installed.sourceAgentDir into the routing in src/main/ipc/pty/host-env/. Verify the OMP path resolution and managed-extension materialization when XDG_DATA_HOME/omp exists, while preserving per-agent selection and the existing fallback behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 58/100