sanil-23andClaude Opus 4.6
c737ebd2fc
Closes the web-channel-side half of the #525 welcome agent routing. Also bundles a small pre-existing Windows compatibility fix for `app_state::ops::sync_parent_dir` that was blocking end-to-end testing of this branch on Windows. ## Web channel routing (primary change) Commit 4b (274b50ed) wired the welcome-vs-orchestrator routing into `channels/runtime/dispatch.rs::process_channel_message` — the handler for inbound messages on external channels (Telegram, Discord, Slack, iMessage, etc.). That path reads `config.onboarding_completed` and selects the right agent via the bus. End-to-end testing on the Tauri desktop app revealed a gap: the in-app chat window does NOT route through `process_channel_message`. It uses its own JSON-RPC method (`openhuman.channel_web_chat` → `start_chat` → `run_chat_task` → `build_session_agent` → `Agent::from_config`) which was hardcoded to build a generic main-agent every turn. So a new user typing in the Tauri app saw the orchestrator immediately, never the welcome agent. This commit closes that gap without adding a third code path: ### `src/openhuman/agent/harness/session/builder.rs` * Split the existing `Agent::from_config` into a thin wrapper + a new `Agent::from_config_for_agent(config, agent_id)`. The wrapper calls the new function with `agent_id = "orchestrator"`, preserving the legacy behaviour byte-identically for all existing callers (CLI, REPL, tests, every call site that doesn't care which agent they get). * `from_config_for_agent` looks up `agent_id` in `AgentDefinitionRegistry::global()` up front; unknown ids fail fast with a clear error. Missing orchestrator is tolerated as a legacy / pre-startup fallback so existing tests that run without a populated registry continue to work. * When a target definition is resolved: - `prompt_builder` uses `SystemPromptBuilder::for_subagent` with the agent's `system_prompt` body (read from the registry, which already has it inlined via `include_str!` from `agents/*/prompt.md` at crate-build time) and the three `omit_*` flags from its TOML. - `visible_tool_names` is built from the agent's `ToolScope::Named` list, unioned with the names of any synthesised delegation tools produced by `collect_orchestrator_tools` (for agents that declare `subagents = [...]`). - `ToolScope::Wildcard` yields an empty filter, matching the legacy "no filter, all visible" semantics. - `temperature` comes from the agent's TOML (e.g. welcome is 0.7, orchestrator is 0.4) instead of `config.default_temperature`. * Legacy behaviour for plain `from_config(config)` — which passes `agent_id = "orchestrator"` — is preserved: the prompt builder continues to use `SystemPromptBuilder::with_defaults()`, temperature comes from `config.default_temperature`, and the orchestrator's `subagents` list drives delegation tool synthesis exactly as before. No test expectations changed. ### `src/openhuman/channels/providers/web.rs` * `build_session_agent` now reads `config.onboarding_completed` and picks `"welcome"` or `"orchestrator"` as the target agent id, then calls `Agent::from_config_for_agent`. Structured info log records the routing decision + the flag state for observability, matching the `[dispatch::routing]` trace pattern from Commit 4b. * `config.onboarding_completed` is read fresh every turn because `run_chat_task` loads the config via `config_rpc::load_config_with_timeout`, which reads from disk on every call (no in-process cache). Welcome → orchestrator handoff therefore happens automatically on the next chat message after `complete_onboarding(complete)` flips the flag, with no explicit event or notification plumbing. * `set_event_context` call is unchanged — the event context is a (session_id, channel_name) pair for telemetry, not the agent id. ## Windows fsync fix (bundled) ### `src/openhuman/app_state/ops.rs` `sync_parent_dir` was calling `File::open(parent).and_then(|dir| dir.sync_all())` on the save path for `app_state.json`. On Windows, opening a directory as a regular file requires `FILE_FLAG_BACKUP_SEMANTICS` which `std::fs::File::open` does not set, so the call fails with "Access is denied. (os error 5)". Mirrored the existing `#[cfg(unix)]` guard already in `config/schema/load.rs::sync_directory`. On non-Unix the function is a no-op and returns `Ok(())`. Durability on Windows is provided by `NamedTempFile::persist`'s atomic `MoveFileEx`, which is sufficient for config files. This is a pre-existing upstream bug, not caused by this PR, but it blocks end-to-end testing of any code path that touches `app_state::save_stored_app_state_unlocked` on Windows — which includes the web channel's agent_server_status RPC. Fixing it here so the #525 routing can actually be tested on the developer's machine, and the fix is tiny and self-contained. The `File` import on line 1 is also gated behind `#[cfg(unix)]` to avoid an unused-import warning on Windows. ## Tests All 35 `agent::harness::session` tests pass, including the transcript round-trip + session queue + runtime tests that exercise the builder path most heavily. No test expectations were modified; the refactor is a pure delegation chain (`from_config` → new inner method → existing builder). CLI dump-prompt testing from the earlier session still validates: * `openhuman agent dump-prompt welcome` → 2 tools, Step 2.5 bare-install prompt embedded * `openhuman agent dump-prompt main` → 6 tools, zero skill leakage * `openhuman agent dump-prompt main --stub-composio` → still 6 tools, composio meta-tools correctly filtered out End-to-end Tauri testing (next step after this commit) will exercise the new `build_session_agent` branch live — user types `hi`, web channel routes to welcome, welcome replies with the updated bare-install prompt from commit990a7264. 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