hermes - 💡(How to fix) Fix [Feature]: Sandbox HOME bridge initialization — subprocess tools can't find Keychain/SSH/Git/Python resources

Problem

When a Hermes Agent profile activates the subprocess HOME sandbox (get_subprocess_home() returns {HERMES_HOME}/home/), system tools that depend on HOME-relative paths break silently. The user sees confusing error messages like "需要授权" (needs authorization) when the real problem is that the tool can't find its resources.

Real-world example (macOS)

After a Homebrew upgrade broke some OpenCLI symlinks, the sandbox HOME compounded the issue:

1. exchange_mail.py (EWS mail) reported "auth config incomplete" — but the real cause was that security find-generic-password (macOS Keychain CLI) looks in ~/Library/Keychains/, which didn't exist in the sandbox
2. op read (1Password CLI) reported "no accounts configured" — because 1Password's desktop app integration socket lives under real HOME, unreachable from sandbox
3. gh auth status and git config failed — because .ssh/, .gitconfig, .config/gh/ don't exist in sandbox

The user experience is broken: tools report auth/config errors that aren't actually auth/config problems — they're environment bridge gaps.

Root cause

The sandbox HOME mechanism is correctly designed for profile isolation, but there is no initialization step that bridges shared system resources into the sandbox. The home/ directory is created empty.

This is the same class of problem as #29584 (skill paths using ~/ break in sandboxed subprocesses), but broader: it affects all system tools that depend on HOME-relative paths.

Proposed Solution

Add a sandbox bridge doctor step to the Hermes install/upgrade flow:

Where

hermes_cli/doctor.py — after the existing "Directory Structure" section that creates home/

What it does

Scans real HOME for known shared resources and creates symlinks into the sandbox:

Shared (auto-bridge):     Keychain, Python site-packages, 1Password config, caches
Identity (auto-bridge):   SSH keys, Git config, GitHub/GitLab CLI configs  
Isolated (no bridge):     OpenCLI, npm, language runtimes (intentionally per-profile)

Design principles

• What exists gets bridged — only create symlinks for resources that actually exist in real HOME
• Idempotent — safe to re-run; won't overwrite or duplicate
• No side effects on real HOME — only creates symlinks in sandbox
• Silent when all good — only reports when something is fixed or broken

Reference implementation

A working implementation exists as a Hermes skill: bridge-doctor skill with scripts/bridge-doctor.py that classifies resources into Shared/Identity/Isolated/Optional tiers, diagnoses bridge status, and auto-fixes with --fix. It also includes a cron wrapper that runs daily in no_agent mode — silent when nothing needs fixing, reports only when bridges are added.

Impact

• Every Hermes user on macOS/Linux who uses tools like gh, git, ssh, op, security, or Python packages will experience confusing failures when the sandbox is active but unbridged
• The fix is additive — it doesn't change the sandbox mechanism, only completes its initialization
• The bridge-doctor approach is platform-extensible: new resource entries can be added to the classification table for Linux-specific paths (D-Bus sockets, etc.)