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

> Explore OpenHuman Rust core environment variables for local development. Configure RPC, AI models, logging, and proxy settings easily without recompiling the binary.

- Repository: [Tiny Humans/openhuman](https://github.com/tinyhumansai/openhuman)
- Tags: how-to-guide
- Published: 2026-05-12

---

**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`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/src/openhuman/config/schema/types.rs).
2. **[`config.toml`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/src/openhuman/main.rs) before the RPC server or UI host starts, ensuring the entire process sees a consistent configuration.

```rust
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:

```bash
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:

```bash
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:

```bash
export OPENHUMAN_CORE_RUN_MODE=inprocess
pnpm dev

```

### Override the LLM model without editing config

Switch to a different provider for a single session:

```bash
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:

```bash
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`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/src/openhuman/config/schema/load.rs) (loader), and [`src/openhuman/config/schema/types.rs`](https://github.com/tinyhumansai/openhuman/blob/main/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.