Environment Variables for Configuring the OpenHuman Rust Core: Complete Local Development Guide

The OpenHuman Rust core reads its runtime configuration from OPENHUMAN_* environment variables defined in .env.example, allowing you to control RPC endpoints, AI models, logging levels, and proxy settings without recompiling the binary.

OpenHuman is an open-source AI platform that uses a Rust-based backend (openhuman-core) to handle LLM inference, skill execution, and process-level RPC communication. During local development, the core loads environment variables from the repository-root .env.example file via scripts/load-dotenv.sh, giving you fine-grained control over network binding, authentication, workspace directories, and feature flags.

Core Network and RPC Configuration

The following variables control how the Rust core binds to your local machine and communicates with the UI layer. These are defined in .env.example (lines 41–60) and parsed at startup in src/openhuman/main.rs.

• OPENHUMAN_CORE_HOST – IP address the HTTP server binds to. Defaults to 127.0.0.1 for local development; use 0.0.0.0 when running inside Docker.
• OPENHUMAN_CORE_PORT – TCP port for the core’s HTTP server. Standard local development value is 7788.
• OPENHUMAN_CORE_RPC_URL – Full RPC endpoint that the Tauri UI or external clients use to communicate with the core, typically http://127.0.0.1:7788/rpc.
• OPENHUMAN_CORE_RUN_MODE – Execution strategy: child (default) spawns the core as a separate process, while inprocess embeds it within the same process as the UI host, useful for debugging.
• OPENHUMAN_CORE_BIN – Absolute path to a custom openhuman-core binary. This bypasses the default search path so you can test local builds without rebuilding the entire workspace.
• OPENHUMAN_CORE_TOKEN – Bearer token for RPC authentication. In local development, this is typically empty; the core auto-generates a token stored in ${OPENHUMAN_WORKSPACE:-~/.openhuman}/core.token.

AI Model and Inference Settings

Configure the default LLM provider, sampling parameters, and tool execution timeouts without touching the TOML configuration files. These settings are sourced from .env.example (lines 70–76) and applied through the Config struct in src/openhuman/config/schema/types.rs.

• OPENHUMAN_MODEL – Identifier for the LLM (e.g., gemini-1.5-pro or gpt-4). When unset, the core falls back to the value in config.toml.
• OPENHUMAN_TEMPERATURE – Sampling temperature for generation, typically 0.7 for creative tasks or 0.0 for deterministic output.
• OPENHUMAN_TOOL_TIMEOUT_SECS – Global timeout for skill and tool execution, defaulting to 120 seconds with a maximum of 3600.
• OPENHUMAN_REASONING_ENABLED – Toggles "reasoning" mode, which adds extra meta-prompting to the inference chain.

Workspace and Data Persistence

Control where the core stores persistent data, including SQLite databases, authentication tokens, and skill caches.

• OPENHUMAN_WORKSPACE – Root directory for persistent data. Defaults to ~/.openhuman (or ~/.openhuman-staging when OPENHUMAN_APP_ENV=staging).
• OPENHUMAN_DOTENV_PATH – Path to an alternate .env file loaded before any other configuration, useful for CI pipelines or machine-specific overrides.

Development and Debugging Features

Enable verbose logging, browser debugging, and Rust-specific diagnostics to troubleshoot the core during active development.

• RUST_LOG – Standard env_logger/tracing filter level (e.g., info, debug, trace). Set to debug to see detailed RPC traffic.
• RUST_BACKTRACE – Set to 1 to enable full Rust stack traces on panic.
• OPENHUMAN_LOG_PROMPTS – Set to 1 to write raw LLM prompts to stderr for inspection; defaults to 0 to protect sensitive data.
• OPENHUMAN_BROWSER_ALLOW_ALL – Set to 1 to disable same-origin policy checks in the embedded CEF browser, essential for debugging local UI assets.

Proxy and Network Routing

Configure HTTP/HTTPS proxy behavior when running behind corporate firewalls or VPNs.

• OPENHUMAN_PROXY_ENABLED – Master switch (true/false) to enable proxy support.
• OPENHUMAN_HTTP_PROXY and OPENHUMAN_HTTPS_PROXY – Proxy URLs (e.g., http://127.0.0.1:3128).
• OPENHUMAN_NO_PROXY – Comma-separated list of hosts to exclude from proxying (e.g., 127.0.0.1,localhost).
• OPENHUMAN_PROXY_SCOPE and OPENHUMAN_PROXY_SERVICES – Fine-grained control over which internal services route through the proxy.

Skills Registry and Local AI

Control where the core discovers skill bundles and which local AI backend to use.

• SKILLS_REGISTRY_URL – Remote Git repository URL for skill bundles; defaults to the canonical OpenHuman registry if empty.
• SKILLS_LOCAL_DIR – Local filesystem path to skill bundles, overriding remote registry lookups.
• OPENHUMAN_LOCAL_AI_TIER – Selects the local inference backend (e.g., ollama, whisper) when running models on-device.
• OPENHUMAN_SKILLS_WORKING_MEMORY_ENABLED – Toggles per-skill "working memory" caching; defaults to true.

Updates and Telemetry

Manage automatic updates, analytics collection, and crash reporting.

• OPENHUMAN_AUTO_UPDATE_RESTART_STRATEGY – Restart method after self-update: self_replace or supervisor.
• OPENHUMAN_AUTO_UPDATE_RPC_MUTATIONS_ENABLED – Allows RPC callers to trigger update.apply; should remain disabled on publicly exposed services.
• OPENHUMAN_ANALYTICS_ENABLED – Toggles telemetry collection; defaults to true.
• OPENHUMAN_CORE_SENTRY_DSN – Sentry DSN for core-side crash reporting.
• OPENHUMAN_BUILD_SHA – Build identifier injected at compile time via option_env!("OPENHUMAN_BUILD_SHA").

How Configuration Loading Works

According to the source code in src/openhuman/config/schema/load.rs, the configuration loader merges three sources in strict order of precedence:

1. Hard-coded defaults defined in src/openhuman/config/schema/types.rs.
2. config.toml values for project-wide defaults.
3. Environment variables – any OPENHUMAN_* value supersedes previous layers.

The loader is invoked early in src/openhuman/main.rs before the RPC server or UI host starts, ensuring the entire process sees a consistent configuration.

use openhuman::config::schema::Config;

/// Load the full runtime config (env vars already applied)
let cfg = Config::load().expect("failed to load configuration");

// Core-specific values
println!("core RPC URL: {}", cfg.core.rpc_url);
println!("workspace dir: {}", cfg.core.workspace);
println!("model: {}", cfg.ai.model.unwrap_or("<default>"));

Practical Local Development Examples

Run the core as a side-car (default)

Copy the example environment file and start the core:

cp .env.example .env

# Optional: use staging backend

echo "OPENHUMAN_APP_ENV=staging" >> .env

# Terminal 1: Start the core

cargo run --bin openhuman-core serve

# Terminal 2: Start the UI (loads .env automatically)

pnpm dev

Test a locally built binary

Build a release binary and point the UI to it:

cargo build --bin openhuman-core --release
export OPENHUMAN_CORE_BIN="$(pwd)/target/release/openhuman-core"
pnpm dev

Debug in in-process mode

Embed the core inside the Tauri host for easier breakpoint debugging:

export OPENHUMAN_CORE_RUN_MODE=inprocess
pnpm dev

Override the LLM model without editing config

Switch to a different provider for a single session:

export OPENHUMAN_MODEL=gemini-1.5-pro
export OPENHUMAN_TEMPERATURE=0.0
pnpm dev

Debug proxy issues

Route traffic through a local proxy while excluding localhost:

export OPENHUMAN_PROXY_ENABLED=true
export OPENHUMAN_HTTP_PROXY=http://127.0.0.1:3128
export OPENHUMAN_NO_PROXY=127.0.0.1,localhost
pnpm dev

Summary

• Environment variables provide the highest precedence configuration layer, overriding config.toml and hard-coded defaults.
• Core networking is controlled by OPENHUMAN_CORE_HOST, OPENHUMAN_CORE_PORT, and OPENHUMAN_CORE_RPC_URL.
• Development workflows rely on OPENHUMAN_CORE_RUN_MODE (child vs inprocess) and OPENHUMAN_CORE_BIN for testing custom builds.
• AI behavior is tuned via OPENHUMAN_MODEL, OPENHUMAN_TEMPERATURE, and OPENHUMAN_LOG_PROMPTS.
• Configuration source files include .env.example (reference), src/openhuman/config/schema/load.rs (loader), and src/openhuman/config/schema/types.rs (schema).

Frequently Asked Questions

How do I point the Tauri UI to a custom-built core binary?

Set the OPENHUMAN_CORE_BIN environment variable to the absolute path of your compiled binary before starting the UI. For example, export OPENHUMAN_CORE_BIN="$(pwd)/target/release/openhuman-core" ensures the UI spawns your fresh build instead of the default cargo path.

What is the difference between 'child' and 'inprocess' run modes?

child mode (the default) spawns the Rust core as a separate OS process, providing isolation between the UI and core crashes. inprocess mode embeds the core within the same process as the Tauri host, which simplifies debugging with breakpoints but means a core panic will crash the entire application.

Where does the core store its authentication token during local development?

When OPENHUMAN_CORE_TOKEN is unset, the core automatically generates a bearer token and writes it to ${OPENHUMAN_WORKSPACE}/core.token, defaulting to ~/.openhuman/core.token. The Tauri UI reads this file to authenticate RPC calls to the core.

How do I enable debug logging for LLM prompts?

Set OPENHUMAN_LOG_PROMPTS=1 in your environment before starting the core. This writes raw prompt text to the logging output (visible when RUST_LOG is set to debug or lower), allowing you to inspect exactly what is being sent to the model provider.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}