Windows: rtk in MSIX/AppContainer hosts (Codex desktop) — analytics DB fails, rg blocked, cmdlet UX

Summary

Three rough edges hit on native Windows when using RTK 0.37.2 from a packaged (MSIX/AppContainer) AI assistant — Codex desktop in this case. One is a real bug (analytics DB), two are UX papercuts (PS cmdlets, rg resolution).

Environment

• OS: Windows 11
• RTK: rtk 0.37.2 (pre-built rtk-x86_64-pc-windows-msvc.zip, dropped into ~/.local/bin)
• Shells tested: PowerShell 7, cmd, Git Bash
• Host AI tool: Codex desktop (MSIX-packaged: C:\Program Files\WindowsApps\OpenAI.Codex_26.422.8496.0_x64__2p2nqsd0c76g0\…)
• User profile path contains a non-ASCII umlaut character (likely irrelevant — rtk gain works fine outside Codex with the same path)

Same RTK install works perfectly from a non-packaged terminal (PowerShell, Windows Terminal, Claude Code on Windows). All three issues only manifest inside the MSIX container.

---

Issue 1 — rtk gain fails to open tracking DB inside MSIX/AppContainer hosts

Repro

From inside Codex desktop (which spawns rtk as a child of an MSIX/AppContainer process):

rtk gain
rtk: Failed to initialize tracking database: unable to open database file: Error code 14: Unable to open the database file

From a regular terminal on the same machine, same binary, same user, same DB:

rtk gain
RTK Token Savings (Global Scope)
…

Works fine.

Diagnosis

MSIX-packaged apps on Windows run their child processes inside an AppContainer that applies per-package file-system virtualization to user-profile writes. Writes intended for %LOCALAPPDATA%\rtk\history.db get silently redirected to %LOCALAPPDATA%\Packages\OpenAI.Codex_<id>\LocalCache\Local\rtk\. SQLite open is sensitive to this — WAL/SHM sidecars (history.db-wal, history.db-shm) don't always co-locate cleanly with the redirected main DB, and sqlite3_open_v2 fails with SQLITE_CANTOPEN (error 14).

Setting LOCALAPPDATA on the Codex process does not help — RTK calls dirs::data_local_dir() which on Windows uses SHGetKnownFolderPath(FOLDERID_LocalAppData), and that API ignores per-process env-var overrides at runtime.

I scanned the binary for env vars and only found these: RTK_CLAUDE_DIR, RTK_DISABLED, RTK_HOOK_AUDIT, RTK_TEE, RTK_TELEMETRY_DISABLED, RTK_TOML_DEBUG, RTK_TRUST_PROJECT_FILTERS.

No way to override the data dir.

Ask

Add an env-var override that takes precedence over dirs::data_local_dir():

• RTK_DATA_DIR (preferred) — override the whole rtk data directory
• or RTK_HISTORY_DB — override just the SQLite path

That lets users (and host-tool RTK.md templates) point rtk at a path outside MSIX redirection (e.g. C:\rtk-data\ on C:\).

The hook itself works inside Codex — commands are getting rewritten and tokens are saved — only the analytics readback fails. So this is purely a tracking/readback issue, but currently there's no way to recover analytics from packaged hosts without uninstalling rtk and re-running outside.

---

Issue 2 — rtk <cmdlet> errors confusingly when the user passes a PowerShell cmdlet

Repro

rtk Get-Content -LiteralPath 'src/lib/api/agentChat.ts' -TotalCount 1
rtk: Failed to resolve 'Get-Content' via PATH, falling back to direct exec: Binary 'Get-Content' not found on PATH
[rtk: program not found]

Why it's confusing

PowerShell users naturally type rtk Get-Content … because it mirrors rtk git … / rtk gh …. The error message ("Binary not found on PATH") is technically correct but doesn't tell the user the right next step. The "Verb-Noun" pattern is a strong cmdlet signal RTK could detect.

Ask

When the first arg matches the cmdlet pattern ^[A-Z][a-z]+-[A-Z] and resolution fails, swap the error for something actionable:

rtk: 'Get-Content' looks like a PowerShell cmdlet, not an executable.
     Try one of:
       - rtk read <file>                   (RTK's own optimized file reader)
       - rtk proxy pwsh -NoProfile -Command "Get-Content -LiteralPath '…'"

Also worth a paragraph in the Windows section of the README — currently it says "Filters work" but doesn't warn users that bare cmdlets won't resolve.

---

Issue 3 — rtk rg blocked by AppX-packaged ripgrep on PATH

Repro

Inside Codex, Get-Command rg resolves to the host-bundled binary:

C:\Program Files\WindowsApps\OpenAI.Codex_26.422.8496.0_x64__2p2nqsd0c76g0\app\resources\rg.exe

rtk rg --version:

[rtk: Zugriff verweigert (os error 5)]

Even rtk proxy pwsh -NoProfile -Command "rg --version" fails — Windows blocks any non-Codex process from launching that rg.exe via AppContainer ACLs.

Workaround that worked for me

Install standalone ripgrep and place it earlier on PATH than the host's resources folder:

winget install BurntSushi.ripgrep.MSVC
copy "%LOCALAPPDATA%\Microsoft\WinGet\Links\rg.exe" "%USERPROFILE%\.local\bin\rg.exe"

…then make sure .local\bin is ahead of any host-bundled resources dirs in user PATH.

Ask

Two non-blocking suggestions:

1. Detect host-bundled binaries — when rtk is about to spawn rg/fd/etc. from a path matching \WindowsApps\ or \AppData\Local\Programs\<host>\…\resources\, log a one-time warning and try a fallback resolution (%USERPROFILE%\.local\bin, %LOCALAPPDATA%\Microsoft\WinGet\Links).
2. Document MSIX hosts in the Windows section: Codex desktop, some VS Code distributions, GitHub Desktop, etc. all run packaged. Recommend installing standalone rg / fd via winget and ensuring .local\bin precedes host paths.

---

Suggested README addition

A short "MSIX / packaged AI hosts" subsection under Windows, covering all three:

When running RTK as a child of an MSIX/AppX-packaged host (Codex desktop, etc.), be aware that:

• The host may bundle binaries (rg, fd) under a WindowsApps\…\resources\ path that AppContainer denies to external processes. Install standalone versions via winget and put them in ~/.local/bin.
• rtk gain analytics may fail to open the tracking DB due to per-package file-system virtualization. (Tracked in #XXX — pending RTK_DATA_DIR env override.)
• PowerShell cmdlets (Get-Content, Select-String) are not on PATH and cannot be invoked as rtk <cmdlet>. Use rtk read, Git-Bash equivalents, or rtk proxy pwsh -Command "…".

---

Happy to test a build with RTK_DATA_DIR if you ship one.