feat(core): pass in-process RPC bearer via internal handle, not process env

[oxoxDev]

Summary

• Stop publishing the in-process core's per-launch RPC bearer token as a process-global environment variable inside the Tauri shell.
• Pass the bearer to the embedded server through an internal Option<Arc<String>> handoff instead.
• Standalone CLI / Docker / cloud-deploy paths that use OPENHUMAN_CORE_TOKEN as configuration are unchanged.

Problem

Post-#1061 the core runs as an in-process tokio task inside the Tauri shell — it is not a child sidecar anymore. The Tauri shell, however, still hands the per-launch RPC bearer to the embedded core by setting OPENHUMAN_CORE_TOKEN as a process-global env var (a leftover from the sidecar era):

// app/src-tauri/src/core_process.rs (pre-change)
std::env::set_var("OPENHUMAN_CORE_TOKEN", self.rpc_token.as_str());

A process-global env var is the wrong transport for an in-process secret. The bearer is then visible to:

• any other process running as the same UID on macOS (sysctl(KERN_PROCARGS2) / ps eww -p <pid> — no TCC prompt, no entitlement, no Accessibility / Full Disk Access requirement);
• any other process running as the same UID on Linux without hidepid configured (/proc/<pid>/environ).

The bearer check itself is correct (constant-time, matches a per-launch hex secret). The problem is purely the transport.

docs/SECURITY_AUDIT.md lines 167 + 186 already track this as an open item ("Review OPENHUMAN_CORE_TOKEN lifetime and exposure scope").

Solution

1. src/core/auth.rs — add a new in-memory init path:

   pub fn init_rpc_token_with_value(token: &str) -> anyhow::Result<()>

   Sets the RPC_TOKEN OnceLock directly. No env read, no file read. The existing init_rpc_token env+file fallback for the standalone CLI / Docker / cloud is untouched.
2. src/core/jsonrpc.rs — extend run_server_embedded_with_ready + run_server_inner to accept Option<Arc<String>>. When the embedded entry is called from the Tauri shell, pass Some(rpc_token); the new helper seeds RPC_TOKEN before any reader runs. When None (standalone CLI / Docker / cloud), fall back to the existing init_rpc_token(workspace_dir) behavior.
3. app/src-tauri/src/core_process.rs — delete the std::env::set_var call; pass the token in via the extended embedded-entry signature. The token already lives in CoreProcessHandle.rpc_token: Arc<String> and is reachable in-memory; no env crossing is needed.
4. src/core/jsonrpc.rs approval-gate session_id reader (:1843-1857) — replace std::env::var("OPENHUMAN_CORE_TOKEN") with crate::core::auth::get_rpc_token(). Same value, sourced from the in-memory RPC_TOKEN post-init. Audit-grouping continuity preserved.
5. scripts/test-webhook-flow.sh — replace the ps eww token-extraction branch with a read of the existing debug-only token file at ${TMPDIR:-/tmp}/openhuman-e2e-rpc-token (already written by core_process.rs under #[cfg(debug_assertions)], mode 0600). Release-build users continue to set the env var themselves, matching the script's existing precedence.
6. docs/SECURITY_AUDIT.md lines 167 + 186 — mark the audit-item resolved.

Init ordering verified

The approval-gate auth::get_rpc_token() read at src/core/jsonrpc.rs:1843 runs inside bootstrap_core_runtime(...) which is awaited from run_server_inner after init_rpc_token_with_value(...) / init_rpc_token(...). Same-task ordering — no race. The bearer is always populated by the time the read happens.

Preserved unchanged (legitimate env-as-config surfaces)

• init_rpc_token env + file fallback at src/core/auth.rs — standalone CLI / Docker / cloud (fly secrets set OPENHUMAN_CORE_TOKEN=...) keep working byte-identically.
• Public-bind warning at src/core/jsonrpc.rs:1417 — operator-supplied config, kept reading env directly.
• Pairing diagnostics at src/openhuman/security/pairing.rs:19, :290, :320-348 — operator-supplied config, kept reading env directly.
• Scripts that intentionally rely on env-as-config (print-core-token.sh, docker-entrypoint-core.sh, test-proactive-welcome.sh, test-subconscious-ticks.sh).
• Tests at src/core/jsonrpc_tests.rs:125, src/openhuman/inference/http/tests.rs:31, tests/inference_provider_e2e.rs:32 (these exercise the CLI / standalone path).
• core_rpc_token Tauri command at app/src-tauri/src/lib.rs:89-93 — already pulls from state.inner().rpc_token(), not env, so no change required.

Submission Checklist

• cargo check --workspace clean
• cargo check --manifest-path app/src-tauri/Cargo.toml clean
• cargo fmt --all -- --check clean
• cargo clippy --workspace --no-deps — zero new warnings on changed lines
• cargo clippy --manifest-path app/src-tauri/Cargo.toml --no-deps — clean on core_process
• cargo test --manifest-path app/src-tauri/Cargo.toml --lib core_process — 27 / 27 pass (including new ensure_running_does_not_publish_token_to_env regression guard)
• cargo test --test json_rpc_e2e --no-run — compiles clean
• N/A: i18n strings — no UI surface touched
• N/A: frontend typecheck / lint / vitest — no TS surface touched
• Release notes — bumped docs/SECURITY_AUDIT.md (item 6 marked resolved)

Note: cargo test --lib core::auth cannot run end-to-end on main right now because src/openhuman/config/ops_tests.rs:631 fails E0063: missing fields ... AutonomySettingsPatch on a clean 87f8ef47 (pre-existing, unrelated to this PR). cargo check --tests --lib compiles my auth.rs tests cleanly. A trivial ..Default::default() fix unblocks the full matrix.

Impact

• Security: removes the leak primitive that lets any same-UID process recover the local RPC bearer via ps eww / KERN_PROCARGS2 / /proc/<pid>/environ. The local RPC surface is the agent control plane, so this is a meaningful local-attack-surface reduction.
• Compatibility: standalone CLI (openhuman-core serve), Docker (docker-entrypoint-core.sh), and cloud-deploy (fly secrets set ...) paths are unchanged. They keep using OPENHUMAN_CORE_TOKEN as configuration via the existing init_rpc_token env + file fallback.
• Dev workflow: scripts/test-webhook-flow.sh now reads the per-launch token from the debug-only mode-0600 file the Tauri shell already writes under #[cfg(debug_assertions)], instead of grepping ps eww output. No behavior change for release-build users.
• Manual macOS verification: after launch, ps eww -p $(pgrep -x OpenHuman) | grep OPENHUMAN_CORE_TOKEN returns no matches; core_rpc_token Tauri command still returns the live bearer; authenticated RPC calls still succeed.

Related

• Sibling defense-in-depth hardening — wallet-side prepared-quote owner binding lands in feat(wallet): bind prepared transaction quotes to originating chat session #2708.
• Resolves an internal audit item tracked in docs/SECURITY_AUDIT.md (lines 167 + 186).
• Follow-up out of scope: the standalone CLI's ~/.openhuman/core.token 0600 file has a similar latent footprint but is operator-managed configuration and lives outside this PR's scope.

AI Authored PR Metadata

• AI authored: yes — implementation produced by a Claude-driven worktree-dev agent following a plan derived via sequential-thinking MCP.
• Human review: all seven commits manually reviewed; tests run locally.

Summary by CodeRabbit

• Security Improvements

  • Desktop app now keeps the core bearer token in-memory (not exposed via process env), reducing token exposure.

• Documentation

  • Docs and guides updated to explain the in-memory token flow and clarify env-var tokens still apply for CLI/docker/cloud.

• Tests

  • Added regression test ensuring desktop startup does not publish the token to the process environment.

• Developer Tools / Scripts

  • Test webhook flow updated to use a debug token file and clearer debug guidance.

[coderabbitai]

📝 Walkthrough

Walkthrough

Move Tauri desktop RPC bearer handling from process-environment variables to an in-memory handoff: add a caller-seeded initializer, extend embedded server startup to accept an optional in-memory token, pass the token from the Tauri host in-memory, and update tests, scripts, and docs.

Changes

Desktop in-memory token handoff

Layer / File(s)	Summary
Core in-memory token initializer src/core/auth.rs	New init_rpc_token_with_value seeds the RPC bearer directly from caller-supplied strings with trimming/validation and idempotency. Tests verify empty-rejection and that re-initialization does not overwrite an already-seeded token.
JSON-RPC server embedded-core token parameter src/core/jsonrpc.rs	run_server_embedded_with_ready and internal run_server_inner now accept rpc_token: Option<Arc<String>>; during bootstrap, prefer the provided token via init_rpc_token_with_value, falling back to env/file-based init. Approval-gate reads active bearer from auth subsystem instead of directly inspecting OPENHUMAN_CORE_TOKEN.
Tauri desktop token capture and in-memory passing app/src-tauri/src/core_process.rs	Remove OPENHUMAN_CORE_TOKEN environment-variable setup from ensure_running; instead clone the internal token into token_for_core and pass it in-memory to run_server_embedded_with_ready(rpc_token: Some(_)). Updated doc comments explain the in-memory handoff mechanism.
Test: ensure_running does not set OPENHUMAN_CORE_TOKEN app/src-tauri/src/core_process_tests.rs	New regression test verifies CoreProcessHandle::ensure_running() does not pollute the process environment with OPENHUMAN_CORE_TOKEN; samples env var before/after spawn with guard-based cleanup.
Configuration, scripts, and documentation updates .env.example, scripts/test-webhook-flow.sh, AGENTS.md, CLAUDE.md, docs/SECURITY_AUDIT.md, src/openhuman/inference/http/tests.rs	.env.example clarifies the variable should be left blank on desktop. test-webhook-flow.sh now resolves the token from OPENHUMAN_CORE_TOKEN or the freshest of core.token and a debug e2e token file. Contributor docs updated to document in-memory handoff, token-file fallback for debugging, and mark prior env-exposure security concern resolved while noting env-as-config remains valid for non-desktop deployments.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• tinyhumansai/openhuman#2114: Related SSE/webhook auth changes that rely on the per-launch bearer plumbing.
• tinyhumansai/openhuman#2011: Modifies embedded server startup/auth-token initialization logic around OPENHUMAN_CORE_TOKEN/RPC bearer handling.
• tinyhumansai/openhuman#2523: Related auth changes touching the in-memory RPC bearer handling in src/core/auth.rs.

Suggested reviewers

• graycyrus
• senamakel

"🐇
A token born fresh for every start,
Kept in memory, safe and smart,
The shell whispers it into the core,
No env to leak, no open door,
Hopping secrets kept secure."

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: moving RPC bearer token passing from process environment to internal in-memory handle for in-process core execution.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/SECURITY_AUDIT.md`:
- Line 167: Update Section 3 to remove the blanket statement that the per-launch
bearer is stored in OPENHUMAN_CORE_TOKEN and instead split the token-flow by
deployment: state that the Tauri/desktop shell no longer exports
OPENHUMAN_CORE_TOKEN to the process environment and performs an in-memory
handoff (use run_server_embedded_with_ready(rpc_token: Some(_)) as the
mechanism), while CLI/docker/cloud deployments continue to accept the bearer via
the OPENHUMAN_CORE_TOKEN env var (env-as-config). Ensure the wording references
OPENHUMAN_CORE_TOKEN and run_server_embedded_with_ready so readers can reconcile
the desktop vs. non-desktop behaviors.

In `@scripts/test-webhook-flow.sh`:
- Around line 17-25: The current token-resolution logic allows a stale workspace
core.token to take precedence over the debug-only TMP token, so update the
resolution order in scripts/test-webhook-flow.sh: first honor
OPENHUMAN_CORE_TOKEN env var, then check for and prefer the debug-only token
file (${TMPDIR:-/tmp}/openhuman-e2e-rpc-token) if it exists and is readable, and
only then fall back to the workspace core.token file; implement this by
reordering the existence/read checks and corresponding assignments (look for the
token-resolution block and variables OPENHUMAN_CORE_TOKEN, the
TMPDIR/openhuman-e2e-rpc-token path, and core.token) so a running Tauri debug
app's live bearer is used when present.

In `@src/core/auth.rs`:
- Around line 158-176: Update the rustdoc comments that still reference the old
Tauri shell env var so they match the new desktop init path: search for and edit
the docs around the constants and functions CORE_TOKEN_ENV_VAR and
init_rpc_token in this file to describe the current desktop boot flow (in-memory
handoff via init_rpc_token_with_value / CoreProcessHandle) instead of saying the
Tauri shell sets OPENHUMAN_CORE_TOKEN, and ensure the module header,
CORE_TOKEN_ENV_VAR docblock, and the init_rpc_token docblock consistently
describe the single current initialization path.

In `@src/core/jsonrpc.rs`:
- Around line 1286-1301: The host-binding security warning logic currently only
checks the OPENHUMAN_CORE_TOKEN env var, so callers passing an in-memory bearer
via rpc_token to run_server_embedded_with_ready are still warned; update the
explicit-token detection to treat rpc_token.is_some() as an explicit auth
configuration (i.e., change the has_explicit_token check used in
run_server_embedded_with_ready and the equivalent check in the related embedded
run_server path) so that when rpc_token is Some(_) and a non-loopback host is
bound, no false public-bind warning is emitted.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 0bb665c9-e503-4890-9d2e-5652cd1ecbe4

📥 Commits

Reviewing files that changed from the base of the PR and between 87f8ef4 and 7d6c349.

📒 Files selected for processing (9)

• .env.example
• AGENTS.md
• CLAUDE.md
• app/src-tauri/src/core_process.rs
• app/src-tauri/src/core_process_tests.rs
• docs/SECURITY_AUDIT.md
• scripts/test-webhook-flow.sh
• src/core/auth.rs
• src/core/jsonrpc.rs

[graycyrus]

@oxoxDev hey! the code looks solid — this is a clean and well-scoped security fix. the approach (OnceLock in-memory handoff, explicit idempotency, removing the env crossing entirely from the Tauri path, regression test) is exactly right. once CI is green i'll approve.

One minor thing I noticed that CodeRabbit didn't catch:

[minor] app/src-tauri/src/core_process_tests.rs — env_during_spawn assertion is redundant and its comment is misleading

In ensure_running_does_not_publish_token_to_env, both env_after and env_during_spawn are captured back-to-back via std::env::var(...) after ensure_running().await returns — no task is spawned in between, and both reads happen at the same instant. The comment says "peek midway via spawning a tiny check task" but no task is actually spawned. The two assertions will always pass or fail together, making env_during_spawn a dead variable. The core regression guard (env_after.is_none()) is correct and sufficient — the second assertion doesn't add coverage. Worth cleaning up so the test is honest about what it proves.

Fix the CI failures and this is good to go.

[graycyrus]

@oxoxDev unresolved review feedback — please address before we review.

[oxoxDev]

@graycyrus — CodeRabbit's four inline items addressed in 040d4c4..361638e: docs split (SECURITY_AUDIT.md desktop vs CLI/docker/cloud transport), freshest-bearer resolution in test-webhook-flow.sh, rustdoc alignment in src/core/auth.rs (CORE_TOKEN_ENV_VAR + init_rpc_token), and in-memory bearer in the has_explicit_token public-bind check in src/core/jsonrpc.rs. Ready for re-review when you have a slot. (5 CI failures remain and are pre-existing main breakage being unblocked by PR #2710; they'll turn green once #2710 merges and I rebase.)

[graycyrus]

@oxoxDev the four follow-up commits look good — docs/SECURITY_AUDIT.md now cleanly separates the desktop in-memory path from CLI/docker/cloud env-as-config, the mtime-based freshest-wins logic in test-webhook-flow.sh correctly handles the stale-standalone-token case, the rustdoc on CORE_TOKEN_ENV_VAR and init_rpc_token is now accurate, and the three-pronged has_explicit_token check (in-memory || env || already-initialized) is a solid defensive improvement.

All CodeRabbit threads are resolved. Still blocked on CI — Rust Core Tests + Quality, Windows Rust Core Tests, Rust Core Coverage, and Build & smoke-test core image are failing. Once those are green I'll approve.

[oxoxDev]

@graycyrus quick status:

• coderabbitai re-reviewed and approved at 2026-05-28T06:01Z after I pushed addresses for all four of its earlier inline notes (docs/SECURITY_AUDIT.md §3 split, scripts/test-webhook-flow.sh freshest-mtime resolution, src/core/auth.rs rustdoc consistency, and src/core/jsonrpc.rs has_explicit_token in-memory branch). Each is acknowledged via <review_comment_addressed> on the original threads.
• CI's earlier failure was a RPC_TOKEN OnceLock race between the new init_rpc_token_with_value_seeds_and_is_idempotent test and the older test_chat_completions_with_bearer_not_rejected_as_auth_error (whichever ran first sealed the OnceLock and the other read a stale value). Just pushed da53de53 making ensure_test_rpc_auth token-agnostic — fix is test-only, no auth-subsystem behavior change.

Re-review when you have a moment 🙏

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/openhuman/inference/http/tests.rs (1)

31-43: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win

Add debug/trace diagnostics to the changed auth-init helper flow.

This helper changed behavior and is now the source-of-truth token provider for tests, but it still has no grep-friendly debug/trace breadcrumbs for init/ready states.

♻️ Proposed update

 fn ensure_test_rpc_auth() -> String {
     static INIT: Once = Once::new();
+    log::trace!("[rpc] ensure_test_rpc_auth: entry");
+
     INIT.call_once(|| {
+        log::debug!("[rpc] ensure_test_rpc_auth: initializing test RPC auth");
         // SAFETY: test-only init; we serialize via `Once`, and live_routing_e2e
         // uses its own env lock + a different token value so the two test
         // binaries don't collide (they run in separate processes anyway).
         unsafe { std::env::set_var(CORE_TOKEN_ENV_VAR, TEST_RPC_TOKEN) };
 
         let tmp = tempfile::tempdir().expect("tempdir for token file");
         crate::core::auth::init_rpc_token(tmp.path()).expect("init rpc auth token for http tests");
     });
-    crate::core::auth::get_rpc_token()
+
+    let token = crate::core::auth::get_rpc_token()
         .expect("rpc bearer must be installed after ensure_test_rpc_auth")
-        .to_string()
+        .to_string();
+    log::debug!(
+        "[rpc] ensure_test_rpc_auth: ready (token_len={})",
+        token.len()
+    );
+    token
 }

As per coding guidelines, Rust changes should include debug/trace diagnosis logs with stable prefixes and must never log secrets (only redacted metadata).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/openhuman/inference/http/tests.rs` around lines 31 - 43, The test auth
helper ensure_test_rpc_auth lacks grep-friendly diagnostics; add
tracing::debug!/trace! calls (use a stable prefix like "[test-auth]") at key
points in ensure_test_rpc_auth: before setting CORE_TOKEN_ENV_VAR (log the env
var name and redact the token value), after successfully calling
crate::core::auth::init_rpc_token (log the tmp path and success), and after
get_rpc_token returns (log that a token was retrieved without printing the
secret, e.g., length or redacted marker). Also emit an error-level trace when
init_rpc_token or get_rpc_token fail, including error details but never the
token itself; reference the functions/vars ensure_test_rpc_auth,
CORE_TOKEN_ENV_VAR, TEST_RPC_TOKEN, init_rpc_token, and get_rpc_token so the
logs are clearly tied to this flow.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@src/openhuman/inference/http/tests.rs`:
- Around line 31-43: The test auth helper ensure_test_rpc_auth lacks
grep-friendly diagnostics; add tracing::debug!/trace! calls (use a stable prefix
like "[test-auth]") at key points in ensure_test_rpc_auth: before setting
CORE_TOKEN_ENV_VAR (log the env var name and redact the token value), after
successfully calling crate::core::auth::init_rpc_token (log the tmp path and
success), and after get_rpc_token returns (log that a token was retrieved
without printing the secret, e.g., length or redacted marker). Also emit an
error-level trace when init_rpc_token or get_rpc_token fail, including error
details but never the token itself; reference the functions/vars
ensure_test_rpc_auth, CORE_TOKEN_ENV_VAR, TEST_RPC_TOKEN, init_rpc_token, and
get_rpc_token so the logs are clearly tied to this flow.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 37c6b734-6343-418f-aeba-18d6844ec04f

📥 Commits

Reviewing files that changed from the base of the PR and between 361638e and da53de5.

📒 Files selected for processing (1)

• src/openhuman/inference/http/tests.rs