cef: per-engine RequestContext cache_path ignored for cookies

[mxaddict]

Problem

BrowserHost::new_with_options creates a per-engine `CefRequestContext` with a custom `cache_path` (`~/.local/share/buffr/engines//`). The context is created successfully — `is_global=0` confirmed via the log added in 9c367fa. We pass it to `browser_host_create_browser_sync` as the `request_context` parameter.

But cookies still flow to CEF's global `Default/` subdirectory under `root_cache_path`, not to the per-engine `cache_path`. `engines/cef/` stays empty even with active browsing.

Evidence

$ ls ~/.local/share/buffr-debug/engines/cef/
(empty)

$ ls ~/.local/share/buffr-debug/Default/
AutofillAiModelCache/  Cache/  Cookies  Code Cache/  Extension*/  ...

Log line proves per-engine context was constructed:

```
INFO buffr_cef::host: per-engine RequestContext created is_global=0
```

Impact

Low for now — only the CEF engine is shipped, so a single global cookie store is fine. Tab-level isolation works (each tab respects same-origin policy). Cross-tab cookie isolation between engine instances doesn't work.

Blocks multi-engine work where each instance wants its own cookie jar (e.g., `work` vs `personal` profiles in the same buffr).

Diagnosis directions

• CEF 147 Alloy vs Chromium runtime may treat per-RequestContext storage differently
• May need explicit `CefRequestContext::GetCookieManager(callback)` bootstrap to materialize the per-context cookie store
• May need a `CefRequestContextHandler` impl
• cef-rs binding might be missing a step in `browser_host_create_browser_sync` request_context propagation

Acceptance

• With multiple engine instances configured, each writes cookies to its own `engines//` cache_path
• `Default/` cookie store no longer accumulates per-engine state

[mxaddict]

Investigation update (2026-05-19)

Spent a long session chasing what turned out to be two separate bugs stacked on top of each other. Documenting for future reference.

Bug 1: Per-engine cache_path is ignored in Alloy runtime (this issue)

Still open, but lower priority than originally framed. Per CEF cef_settings_t docs:

"Any child directory value will be ignored and the 'default' profile (also a child directory) will be used instead."

CEF Alloy runtime supports a single profile. engines/<id>/ will stay empty even with is_global=0 on the per-engine CefRequestContext. Browser writes land in <root_cache_path>/Default/ regardless of the per-engine cache_path.

Workaround for now: ignore per-engine isolation in Alloy. Use single engine.

Real fix: drop forced Alloy (CEF_RUNTIME_STYLE_ALLOY), let CEF pick Chrome runtime which actually supports multi-profile. Trade: Chrome runtime spawns its own window for embedding (the whole reason Alloy was forced). Needs OSR-mode evaluation under Chrome runtime in CEF 147+.

Bug 2: Cookies don't persist at all (system, not buffr)

Discovered mid-investigation. Affects ALL Chromium-based browsers on this machine, not just buffr.

• Login state lost between buffr restarts
• All other Chromium stores persist fine: History, Favicons, Web Data, Login Data (file), Cache/ (445KB+), Local Storage leveldb
• ONLY Cookies file stays at 0 rows
• Stock Chromium 148.0 on the same machine reproduces 0 cookies for a fresh profile + google.com

Root cause: pass-secret-service runs and exposes org.freedesktop.Secret D-Bus. Chromium auto-detects → tries OSCrypt encryption → unlock/auth fails → drops cookies rather than persist unencrypted. This is intentional Chromium security policy.

Escape hatch: --password-store=basic forces scrypt-derived key (no keyring round-trip). Documented at https://chromium.googlesource.com/chromium/src/+/master/docs/linux/password_storage.md.

Fix shipped in d240093: CEF requires the switch on BOTH browser process AND every subprocess command line. CEF does NOT propagate user-added switches automatically — each subprocess argv is rebuilt at spawn time. Implementation:

1. Browser process: appended in on_before_command_line_processing
2. Subprocesses: appended in new on_before_child_process_launch hook on BrowserProcessHandler

Verified live: every buffr-app child PID has the switch in /proc/<pid>/cmdline.

Things tried that didn't work (record so we don't redo)

Approach	Why ruled out
persist_session_cookies = 1 on Settings + RequestContextSettings	Cookies still dropped — encryption fails before this matters
Settings.cache_path = root_cache_path	Doesn't change cookie store location
fs::create_dir_all per-engine cache path	Dir exists empty, CEF Alloy still collapses to Default/
flush_store() + do_message_loop_work pump on shutdown	Not a shutdown-flush issue; other stores flush fine
std::process::exit(0) over libc::_exit(0)	Same — not a destructor issue
--password-store=basic on browser process only	Subprocesses don't inherit it (this issue)
--use-mock-keychain on Linux	Doesn't apply to OSCrypt's Linux backend selection
Pause / kill pass-secret-service	D-Bus auto-activates it on probe
Skip per-engine RequestContext entirely (pass None)	Cookies still 0 — confirms bug is downstream of context

What's still open (in this issue)

Per-engine context isolation in Alloy. Tracked here. Not user-impacting until we ship multi-engine to real users.

Related memory

project_buffr_cef_persistence.md in the dev's local memory — historical record of the full diagnostic chain.

[mxaddict]

Resolved (kind of): cookies now persist; per-engine isolation still off

Follow-up to the diagnosis comment. The cookie persistence bug is now fixed — verified live:

Configuration	Result (50s hold + clean SIGTERM)
Per-engine RC + --password-store=basic	0 cookies
No per-engine RC + --password-store=basic	3 cookies for .google.com ✅
Stock Chromium + --password-store=basic	3 cookies (control)

Two fixes stacked:

• d240093 — propagate --password-store=basic to every CEF subprocess via OnBeforeChildProcessLaunch
• 8660ba8 — drop per-engine CefRequestContext creation (it was silently blocking persistence on top of Alloy's known cache-path collapse)

This issue is still about per-engine isolation

Original framing of this issue — "per-engine RequestContext cache_path ignored for cookies" — remains accurate but is now confirmed to be a known CEF Alloy runtime limitation, not a bug we can fix in buffr.

Two paths forward:

1. Drop forced Alloy → Chrome runtime supports multi-profile properly. Trade: Chrome runtime spawns its own window (the very reason we force Alloy in host.rs:1265). Needs evaluation of whether OSR mode is viable under Chrome runtime in CEF 147+.
2. Accept single-profile and remove the data_dir plumbing entirely. Re-introduce when (1) lands.

Closing notes:

• Earlier "stock Chromium also fails" reproductions were due to my too-short test windows (15s vs Chromium's ~30s flush cadence). With ≥45s holds, stock Chromium persists fine — confirms this was buffr-only.
• The --password-store=basic propagation fix is correct and stays regardless of which path we take above.
• Decision on filing upstream: no — what we found turned out to be our own code, not Chromium. The closest Chromium-side gap (silent cookie drop when Secret Service is broken) is intentional security policy that Chromium team has discussed and will not change.