sanil-23andClaude Opus 4.6
56d95e2c38
End-to-end testing on the Tauri desktop app revealed that the welcome
agent could never run from the in-app chat pane — even with all of
Commits 4b/8 in place — because the React layer's
`OnboardingOverlay.tsx` renders a full-screen wizard whenever
`onboarding_completed = false` and gates the chat pane behind it. By
the time a user can type a chat message the React wizard has already
flipped `onboarding_completed = true` (via `OnboardingOverlay::handleDone`
or the `Onboarding.tsx` wizard's completion handler), so the welcome
agent's routing condition is never satisfied on the Tauri surface.
This commit fixes the architectural conflict by splitting the single
`onboarding_completed` flag into two orthogonal flags:
* **`onboarding_completed`** — unchanged semantics. Tracks whether the
React UI wizard has been completed/dismissed. Continues to be set
by `OnboardingOverlay.tsx::handleDone` and `Onboarding.tsx` via the
existing `config.set_onboarding_completed` JSON-RPC method. Used
exclusively to gate whether the React layer renders the wizard.
* **`chat_onboarding_completed`** — NEW. Tracks whether the welcome
agent's chat-based greeting flow has run. Set exclusively by the
welcome agent itself via `complete_onboarding(action="complete")`.
Used by both the Tauri web channel
(`channels::providers::web::build_session_agent`) and the external
channel dispatch path (`channels::runtime::dispatch::resolve_target_agent`)
to decide whether to route to welcome or orchestrator.
The two flags are intentionally orthogonal:
* A Tauri desktop user completes the React wizard → only
`onboarding_completed` flips → wizard disappears → user types `hi`
→ welcome agent runs (because `chat_onboarding_completed` is still
false) → welcome calls `complete_onboarding(complete)` →
`chat_onboarding_completed` flips → next chat turn routes to
orchestrator.
* A Telegram/Discord user (no React wizard exists) sends a message
→ external channel dispatch checks `chat_onboarding_completed` →
routes to welcome → welcome runs → flips the flag → next inbound
message routes to orchestrator.
Both paths give every user the chat welcome experience, regardless of
which surface they came in through, and without requiring the React
wizard to be removed or restructured.
## Files changed
`src/openhuman/config/schema/types.rs`
* Add `chat_onboarding_completed: bool` field with `#[serde(default)]`
for backward compat — existing `config.toml` files that don't have
the field default to `false`, which means existing users will see
the welcome agent on their next chat turn (correct behaviour, the
welcome agent is idempotent).
* Default impl initializes the new field to `false`.
* Extensive rustdoc on both flags explaining the orthogonal split,
why two flags exist, and which code paths gate on which.
`src/openhuman/tools/impl/agent/complete_onboarding.rs`
* `check_status` now reports BOTH flags side-by-side so the welcome
agent's LLM can see whether the React wizard has run AND whether
the chat welcome itself has run. Old single "Onboarding completed"
line replaced with two lines: "UI onboarding wizard completed" and
"Chat welcome flow completed".
* `complete()` now flips `chat_onboarding_completed`, NOT
`onboarding_completed`. The React UI's flag is left untouched —
that's owned by the React layer. Idempotency guard updated to
check the chat flag.
* Rustdoc on `complete()` explains the orthogonal-flags rationale
for future readers.
`src/openhuman/channels/providers/web.rs::build_session_agent`
* Reads `effective.chat_onboarding_completed` instead of
`effective.onboarding_completed` for the welcome-vs-orchestrator
decision.
* Log line now includes BOTH flags so observability captures the
full picture (e.g. `chat_onboarding_completed=false,
ui_onboarding_completed=true` is the expected steady state for a
Tauri user who completed the React wizard but hasn't typed yet).
`src/openhuman/channels/runtime/dispatch.rs::resolve_target_agent`
* Same flag swap for the external-channel path.
* `[dispatch::routing] selected target agent` info trace also
reports both flags.
* Function-level rustdoc updated with the new semantics.
## Backward compatibility
* Existing `config.toml` files: `chat_onboarding_completed` defaults
to `false` via `#[serde(default)]`. Means existing users get a
welcome message on their next chat turn — this is the desired
behaviour, not a regression.
* React layer: untouched. The `config.set_onboarding_completed`
JSON-RPC method continues to write the same field; the new flag is
not exposed to React at all.
* External callers of `complete_onboarding(complete)`: they now flip
a different flag. This may matter for callers who were depending
on the flag flip side effect; a quick grep shows
`tools/impl/agent/complete_onboarding.rs` is the only caller and
the rest of the codebase reads `onboarding_completed` for UI
purposes (snapshots, app state) and `chat_onboarding_completed`
for routing — the split is clean.
## Tests
399/400 tools tests pass. The single failure
(`tools::impl::browser::screenshot::screenshot_command_contains_output_path`)
is a pre-existing Windows-environment bug that fails identically on
`upstream/main` baseline and is unrelated to this PR. No test
expectations were modified.
## Next step
Restage sidecar, relaunch Tauri, click through the React wizard once
to dismiss it, then type `hi` in the chat pane. This time
`build_session_agent` should read `chat_onboarding_completed=false`
and route to welcome, even though `onboarding_completed=true` was set
by the React layer.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
OpenHuman
The age of super intelligence is here. OpenHuman is your Personal AI super intelligence. Private, Simple and extremely powerful.
Discord • Reddit • X/Twitter • Docs
"The Tet. What a brilliant machine" — Morgan Freeman as he reminisces about alien superintelligence in the movie Oblivion
Early Beta — Under active development. Expect rough edges.
To install or get started, either download from the website over at tinyhumans.ai/openhuman or run
# For MacOS/Linux
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash
# For Windows
irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex
What is OpenHuman?
OpenHuman is an open-source agentic assistant that is designed to integrate with you in your daily life. Here's what makes OpenHuman special:
-
Simple, UI-first — A clean desktop experience and short onboarding paths so you can go from install to a working agent in a few clicks, without a config-first setup. You don't need a terminal to run OpenHuman.
-
One subscription, many providers — You only need one account to get access to many agentic APIs (AI Models, Search, Webhooks/Tunnels and other 3rd party APIs etc..), simplifying the experience to get a powerful agent going.
-
Rich Skills — Plug into Gmail, Slack, Notion, and the rest of your stack via rich, feature-backed skills. Connections are typically one click through setup wizards instead of wiring APIs by hand. Workflow data is kept on device, encrypted locally, and treated as yours: encryption and sensitive context stay on your machine. Webhooks give instant feedback into the agent when external systems or skills emit events, so the loop stays tight without constant polling.
-
Local knowledge base — Built from your data and your activity. How you work across tools, sessions, and connected services—so the agent gets rich, workflow-aware context, not a one-off chat transcript. Everything is stored on your machine and compounding over time without becoming a cloud dossier. Channels, skills and ongoing conversations feed the same loop so day-to-day context does not reset every session.
-
Local AI model — The Rust core exposes local AI paths (and the desktop bundle can ship local/bundled runners where applicable) for the workloads above—vision snippets, speech helpers, summarization, tooling—so sensitive steps can stay off the cloud when you choose.
-
Deep desktop integrations — OpenHuman is a native desktop assistant, not a web-only chat: memory-aware keyboard autocomplete, voice (STT listening and TTS replies), screen intelligence that understands what is on screen and feeds your local context, plus windowing and OS-level permissions—so the agent meets you on the machine, not trapped in a browser tab.
Architecture: docs/ARCHITECTURE.md. Contributor orientation: CONTRIBUTING.md.
OpenHuman vs other agents
High-level comparison (products evolve—verify against each vendor). OpenHuman is built to minimize vendor sprawl, keep workflow knowledge on-device, and ship deep desktop features—not only chat.
| Claude Code/Cowork | OpenClaw | Hermes Agent | OpenHuman | |
|---|---|---|---|---|
| Open-source: Is the codebase open to review? | 🚫 Proprietary client | ✅ MIT License | ✅ MIT License | ✅ GNU License |
| Simple: Is it simple to get started? | ✅ Simple Desktop App + CLI | ⚠️ Terminal first and often complex | ⚠️ Terminal first and often complex | ✅ Simple, Clean UI/UX. Get started within minutes |
| Cost: How expensive is to run? | ⚠️ Subscription + add-on tool/API costs | ⚠️ Tied to models & hosting you choose | ⚠️ Tied to models & hosting you choose | ✅ Cost optimized with the option to run many things locally for free |
| Memory & Knowledge Base (KB): Does the agent know you and your world? | ✅ Built-in memory; mostly chat/session scoped | ⚠️ Has a local memory but often needs plugins for richer behavior | ✅ Self-learning / task loops (typical) | 🚀 Local KB + Self-learning from your activity & data (GMail, Notion etc... via skills) & prompts |
| API spagetti: How complex is it to hook mulitple features together? | 🚫 Claude bill + often extra keys for MCP/tools | 🚫 BYOK / multi-vendor common | 🚫 Multiple providers common | ✅ One account get access to many bundled platform APIs |
| Extensibility: Can you add rich features into it? | ✅ MCP (different model than sandboxed skills) | ✅ Plugin Architecture (SKILL.md) | ✅ Plugin Architecture (SKILL.md) | 🚀 Rich Skills with ability to have realtime updates, local DB & more |
| Desktop integrations: Can it integrate into your desktop completely? | ⚠️ Desktop app & access to folders | ⚠️ Often lighter native surface | ⚠️ Often lighter native surface | ✅ STT, TTS, screen intelligence, memory-aware autocomplete and a whole lot more |
Contributors Hall of Fame
Show some love and end up in the hall of fame