Repository navigation
[Bug] Service Required screen: Load failed and buttons disabled on app startup #129
Description
Summary
On app startup, the "OpenHuman Service Required" screen shows "Load failed" and all action buttons (Install, Start, Stop, Restart, Uninstall) are disabled — the user is stuck with no way to recover.
Problem
What happened: App launches to the Service Required gate screen. It attempts to connect to the core daemon at http://127.0.0.1:7788/rpc and fails. A red "Load failed" banner appears. All buttons except Refresh are grayed out and unclickable.
What was expected: The Install Service and Start Service buttons should be usable so the user can bootstrap the daemon from this screen.
Impact: Blocks the entire app — user cannot get past this screen.
Steps to reproduce:
- Fresh install of the app (or core daemon not running)
- Launch the app
- "OpenHuman Service Required" screen appears
- Service: Unknown, Agent Server: Not Running, "Load failed" in red
- All buttons disabled except Refresh
Platform: macOS (desktop)
Solution
Root cause: Catch-22 in ServiceBlockingGate.tsx. When the RPC health check fails:
- Service state is set to
"Unknown" - The button disable logic derives
installed = (serviceStateText !== 'NotInstalled')— but"Unknown"doesn't match any known state, soinstalledresolves tofalsein practice - Most buttons require
installed === trueto be enabled (Install requires!installed, but it also requires the RPC to succeed to execute) - The buttons that should help recover (Install, Start) are disabled by the very state they need to fix
Proposed fix:
- Enable Install and Start buttons when state is "Unknown" — these are the recovery actions and should always be clickable
- Clear error banner on retry — currently the error persists even if the user clicks Refresh
- Route Install/Start through Tauri commands directly instead of RPC when the daemon isn't reachable — the RPC server is the daemon itself, so you can't ask it to install/start itself if it's not running
Key files:
app/src/components/daemon/ServiceBlockingGate.tsx— gate component with button disable logicapp/src/services/coreRpcClient.ts— RPC client hitting :7788app/src-tauri/src/core_process.rs— core process managementsrc/openhuman/service/macos.rs— macOS LaunchAgent install/startsrc/openhuman/service/common.rs— daemon executable resolution
Acceptance criteria
- Install Service and Start Service buttons are enabled when service state is Unknown or Load failed
- Error banner clears when user retries or clicks a button
- Service can be installed and started from the blocked screen without the daemon already running
- Repro gone — fresh install shows working buttons on the Service Required screen
- Regression safety — existing service management flows still work when daemon is already running
Related
Priority: High — blocks app startup for new users.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
zahica1234 commentedon May 11, 2026
Same on Windows v0.53.22 (x64), reproduced with both installers.
Both
OpenHuman_0.53.22_x64_en-US.msiandOpenHuman_0.53.22_x64-setup.exeinstallidentical contents to
%LOCALAPPDATA%\OpenHuman\. No core daemon binary is shipped.Diagnostic evidence:
OpenHuman.exe(110 MB, the UI).bootstrap.exe,bootstrapc.exe, 2.8 MB each) reportthemselves as "CEF Bootstrap Application" (Chromium 146.0.7680.165) in VersionInfo
and crash with
[FATAL:cef/libcef_dll/bootstrap/bootstrap_win.cc:387] Missing module namewhen run standalone. They're not the Rust core.
openhuman*.exeandopenhuman-core*.exereturns only
OpenHuman.exeand the downloaded installers._up_\_up_\src\openhuman\agent\prompts\*.rssource files —suggests a path-traversal issue in the build script's resource bundling.
libcef.dll(262 MB), which contradicts the README's "Rust/Tauri"architecture (Tauri targets WebView2 on Windows, not CEF).
Result: app launches to "Service Required" → "Load failed", all buttons disabled,
no way to install/start a service because the daemon binary is not present on disk.
Service Required screen recovery (the original bug) is one issue, but a more fundamental
packaging bug is sitting underneath it on Windows.
chore(vendor): bump tinyagents, tinymcp, tinymemory, tinyvoice, tinys…