Bug Description

When HERMES_HOME contains symlinks (for example config.yaml symlinked to a git-tracked profile package), Hermes writes to that path via atomic replace and the symlink is replaced by a regular file.

This causes managed package setups to drift: runtime keeps working, but git-tracked source-of-truth is silently detached.

Steps to Reproduce

1. Create ~/.hermes/config.yaml as a symlink to another file:

ln -s /path/to/tracked/config.yaml ~/.hermes/config.yaml

2. Trigger any Hermes path that writes config (e.g. gateway /sethome, or settings write path).
3. Inspect ~/.hermes/config.yaml.

Expected Behavior

If the target path is a symlink, writes should preserve link semantics (or provide an explicit supported mode for managed symlink deployments).

Actual Behavior

Symlink is replaced with a regular file at ~/.hermes/config.yaml.

Affected Component

Config + gateway write paths using atomic replace helpers.

Related

• [Bug]: Gateway /sethome command writes channel ID in config.yaml instead of .env file #6447 (/sethome persists into yaml path)
• [Bug]: Home-channel auto-prompt only checks env var, never falls back to yaml config #10581 (home-channel prompt/source mismatch)
• Managed/shared Hermes runtime: atomic writes recreate SKILL.md and .bundled_manifest as 0600, causing permission-denied failures #14181 (atomic writes and metadata/permissions drift in managed installs)

Why this matters

Managed/shared deployments often separate runtime home from package canon using symlinks. Replacing symlinks breaks that contract and causes config/persona drift unless operators add periodic relink scripts.