Triage request: 5 issues surfaced by remote-core attach-mode investigation (attach-mode silent, daemonlifecycle recurrence, configPersistence printer, cross-host path leak, active-user re-resolution)

[leighstillard]

Summary

While trying to get a Windows desktop client (0.54.0) to attach to a remote openhuman-core over a private network, a multi-layer diagnostic surfaced five distinct issues. Filing as a single triage ask so a maintainer can split / prioritize / dedupe before any of them get worked on. I'm volunteering to take #A first if the maintainers concur, but want input before opening PRs.

Diagnostic context: Windows 0.54.0 installed via MSI, launched via openhuman://auth/?token=... deep link after web sign-in. Remote Linux openhuman-core 0.54.0 running with OPENHUMAN_CORE_HOST=0.0.0.0 OPENHUMAN_CORE_PORT=4000 on a Tailscale-only host. Bundle id on Windows is com.openhuman.app; logs live at %USERPROFILE%\.openhuman\logs\openhuman.<date>.log (Rust shell, sparse — only [app-update] heartbeats) and %USERPROFILE%\.openhuman\users\local\cef\chrome_debug.log (CEF renderer, 44 MB / 31 h session, all real activity).

---

A. Attach mode is silently inoperative when the app is launched via deep link

Severity: high — the entire "remote core" capability is unreachable for normal users.

Attach mode is configured only via env vars (OPENHUMAN_CORE_REUSE_EXISTING, OPENHUMAN_CORE_URL, OPENHUMAN_CORE_TOKEN). On Windows, the standard launch path is the Start Menu shortcut (no Arguments, no env) and the deep-link handler (openhuman://auth/... → invoked via DCOM/explorer, inherits the explorer.exe environment). Neither path can carry those env vars, so the app falls back to spawning its own in-process core regardless of what the user thinks they configured. There is no UI affordance to point at a remote core URL, no obvious failure mode in the renderer, and the renderer log doesn't reference attach state at all.

Confirmed in the diagnostic: [Environment]::GetEnvironmentVariables at User and Machine scope contain none of those names; the Start Menu shortcut has zero arguments and zero env; the running process was launched via deep link from explorer.

Proposal — discussion before code: make remote-core URL + token a first-class persisted setting (Settings → Advanced → Core), with an explicit "use remote core" toggle, plus a visible status indicator in the UI ("connected to remote core at … as user …"). Env vars stay as an override for dev. Possibly add a one-shot import command (openhuman://attach?url=…&token=…) so a user on the headless server can copy a single URL into the desktop to wire it.

B. [configPersistence] Stored RPC URL: [object Object] printer bug

Severity: low; impedes self-diagnosis.

At renderer init, configPersistence logs Stored RPC URL: [object Object] instead of the URL string. Almost certainly logging the wrapper object instead of .url. Trivial fix; mostly worth filing because it actively hid the cause of (A) in user-reported logs.

C. DaemonLifecycle setup/teardown loop has returned post-#2151

Severity: medium — sustained log spam and CPU; masks real lifecycle transitions.

Same symptom as issue #2151 (closed): [DaemonLifecycle] Setting up daemon lifecycle management / Cleaning up daemon lifecycle management alternating continuously, with [analytics] GA consent updated: enabled=true firing on each cycle. On the current Windows 0.54.0 session: 105,704 setup / 105,702 teardown / 52,831 GA-consent lines in 31 hours, i.e. one full cycle every ~1 s, indefinitely. Suggests the original fix did not hold (or the regression came in on a different code path). Worth either reopening #2151 or filing a fresh issue cross-referencing it.

D. Linux paths leak into Windows config (/home/leigh/OHvault on a Windows host)

Severity: high — cross-host config corruption.

Windows renderer log:

[ui-flow][vault-panel] create failed CoreRpcError: root_path is not a directory: /home/leigh/OHvault

That's a Linux absolute path being used as a vault root_path on a Windows machine. Either configPersistence is syncing filesystem paths across hosts via the backend without per-host scoping, or the backend stores absolute paths verbatim and replays them. Either way, any user who runs OpenHuman on more than one OS will hit this.

Proposal — discussion before code: filesystem paths should never be cloud-synced unscoped. Either store paths in a per-host bucket keyed by host id, or refuse to round-trip filesystem paths from the backend at all and treat them as device-local settings.

E. Active-user not re-resolved by long-running subsystems after store_session

Severity: medium — silent data fragmentation across user dirs.

On the Linux box, the openhuman-core process was started before any user had logged in. It opened its memory DB at ~/.openhuman/users/local/workspace/memory/memory.db and its CEF/etc. profiles under users/local/. Later, a sign-in over RPC triggered credentials::ops::store_session, which wrote ~/.openhuman/active_user.toml and created ~/.openhuman/users/<user_id>/. But the running process's open file handles never migrated — lsof / /proc/<pid>/fd still showed every DB under users/local/. config::schema::load::resolve_config_dirs only reads active_user.toml on each Config::load; long-lived subsystems (memory, channel runtime, scheduler) hold cached Config snapshots from startup and never re-resolve.

Effect: after first login, the user's data continues writing to users/local/, while a fresh restart would correctly route to users/<user_id>/. Telegram channel config saved post-login would land in a place the running core no longer reads. (Reported repro is fragile because most users restart soon after login; the bug only becomes visible on a long-lived headless deployment.)

Proposal — discussion before code: store_session should either (1) trigger a controlled subsystem reload (memory pool re-open, channel runtime restart, scheduler re-bind) against the new user dir, or (2) explicitly require a process restart and surface that requirement in the response. Quietly continuing on the wrong user dir is the worst of both worlds.

---

Triage ask

I would like maintainer input on:

1. Should these be five separate issues or stay consolidated? I'll split if preferred.
2. Priority order from the maintainers' perspective. From a user POV my order is A > E > D > C > B but maintainers may weigh differently.
3. Should #C be a reopen of Daemon lifecycle loops between setup and cleanup #2151 or a fresh issue?
4. For #A specifically: is the desired direction "first-class remote-core setting in the UI", or is attach mode intended to remain a dev/internal capability? That decision changes the scope significantly.

I'm prepared to start on #A as soon as direction is agreed. Will not open PRs on #B–#E without explicit go-ahead.

Related

• Issue Daemon lifecycle loops between setup and cleanup #2151 (closed) — Daemon lifecycle loops between setup and cleanup. Symptom recurs as described in #C above.
• PR fix(security): replace wildcard CORS on core RPC with origin allowlist #2266 (merged) — fix(security): replace wildcard CORS on core RPC with origin allowlist. Same investigation thread; this triage is the next pass.

Full Windows diagnostic transcript

Raw output from Windows-side diagnostic (CEF process tree, renderer log patterns, registry, env)

• App install: C:\Users\leigh\AppData\Local\OpenHuman\OpenHuman.exe, ProductVersion 0.54.0, bundle id com.openhuman.app.
• Logs: %USERPROFILE%\.openhuman\logs\openhuman.<date>.log (Rust shell, sparse) + %USERPROFILE%\.openhuman\users\local\cef\chrome_debug.log (44.5 MB renderer console).
• Renderer pattern counts (31 h session): DaemonLifecycle 210,932 · [analytics] GA consent 52,831 · telegram / channels_config / store_session / attach / core_rpc / OPENHUMAN_CORE 0 · [core-state] poll failed 42 · auth_get_me timed out 30000 ms (repeated) · composio_list_connections → 502 Bad Gateway from api.tinyhumans.ai.
• Startup excerpt:

  12:49:29 [cef-profile] honoring pre-set OPENHUMAN_CEF_CACHE_PATH=C:\Users\leigh\.openhuman\users\local\cef
  12:49:29 [webview_apis] server listening on 127.0.0.1:54216
  12:49:29 [tray] tray icon ready
  12:49:29 [analytics] GA initialized [object Object]
  12:49:29 [configPersistence] Stored RPC URL: [object Object]
  12:49:29 [memory] syncMemoryClientToken: entry (token_present=%s, is_tauri=%s) true true
  12:49:29 [memory] syncMemoryClientToken: payload → memory.init (local-only)
  12:49:29 [onboarding-gate] redirecting / -> /onboarding (onboarding incomplete)
  

• URL scheme: HKCR/HKCU openhuman both present, point at the installed exe; deep-link launch works.
• Process: main PID launched via openhuman://auth/?token=<JWT> (userId 6a0d…, iat 2026-05-19, exp 2026-08-17). Parent PID was explorer/DCOM (already gone). CEF remote debugging is live on 127.0.0.1:19222 and the webview_apis bridge on 127.0.0.1:54216.
• Env vars OPENHUMAN_CORE_REUSE_EXISTING, OPENHUMAN_CORE_URL, OPENHUMAN_CORE_TOKEN are absent at both User and Machine scope; the Start Menu shortcut has no Arguments and no environment block.

[leighstillard]

Concrete evidence for E (active-user not re-resolved after store_session)

Pulled /proc/<pid>/fd on a running openhuman-core on Linux (v0.54.0, started pre-login, signed in afterwards via the desktop). The process now holds two memory DBs open in parallel:

13 -> /home/leigh/.openhuman/users/local/workspace/memory/memory.db
14 -> /home/leigh/.openhuman/users/local/workspace/memory/memory.db-wal
15 -> /home/leigh/.openhuman/users/local/workspace/memory/memory.db-shm
26 -> /home/leigh/.openhuman/users/6a0d1e3731708656b3875ed2/workspace/memory/memory.db
29 -> /home/leigh/.openhuman/users/6a0d1e3731708656b3875ed2/workspace/memory/memory.db-shm
31 -> /home/leigh/.openhuman/users/6a0d1e3731708656b3875ed2/workspace/memory/memory.db
32 -> /home/leigh/.openhuman/users/6a0d1e3731708656b3875ed2/workspace/memory/memory.db-wal

So on login store_session did trigger something to open the new user dir (good — partial re-resolution exists), but the pre-login users/local/ handles were never closed. Net effect: writes can race / split across two databases, depending on which subsystem cached which Config snapshot. This is worse than "pinned to local forever" — it's silent data fragmentation.

The users/6a0d…/workspace/ tree also shows recent activity (memory_tree/ mtime 11:07 today, whatsapp_data/ mtime 10:31 today), so the auth'd user dir is being written to as well. Confirms the split is live, not just a stale handle.

Suggests two distinct fixes for E rather than one:

1. Close the pre-login handles when transitioning local → user, not just open new ones.
2. Audit which subsystems re-resolved and which didn't — three handles on local vs four on the auth'd user implies an inconsistent migration, not a clean swap.

I'll keep this branch parked until maintainer direction lands on the priority/scope question above.

[leighstillard]

Two smaller observations from a Slack-sync session, raising as a separate comment so they don't get conflated with E

While diagnosing a [composio:slack] daily request budget exhausted log line, two adjacent annoyances surfaced. Posting for visibility — not asking either to be in scope for the triage, just noting them in case maintainers want to spin separate issues.

F. The interval-vs-budget ratio is unreachable from config.

• DEFAULT_DAILY_REQUEST_LIMIT = 500 (src/openhuman/composio/providers/sync_state.rs:32)
• Slack SYNC_INTERVAL_SECS = 15 * 60 (src/openhuman/composio/providers/slack/provider.rs:104)

Neither is exposed as an env var, RPC, or config field. The provider records requests at five separate call sites per sync, so any moderately-active Slack workspace burns ≥10/tick × 96 ticks/day ≫ 500 budget → guaranteed mid-day exhaustion on day one, every day. There's no way to widen the budget or slow the interval without recompiling. Either field would be a one-line addition to ChannelsConfig (or a new ComposioConfig section).

G. No "budget reset" log line at date rollover.

There's the daily request budget exhausted, skipping sync log (slack/provider.rs:406, plus the identical lines in gmail/provider.rs:235, notion/provider.rs:161, clickup/provider.rs:169), but no symmetric "budget reset, N requests available" line when today_str() changes inside DailyBudget::record_requests (sync_state.rs:129–136). Hard to tell from logs alone whether sync actually resumed the next day vs is still wedged on yesterday's is_exhausted() == true cached read. Tiny instrumentation gap; a one-line tracing::info! in the reset branch would fix it.

Both are low-priority. If maintainers want them split out as issues I'm happy to. F probably wants design input (where in config does it belong, does it get a per-provider override, etc.); G is essentially a one-liner.