Finding
The renderer's default certificate/credential directory is the literal string "~/.config/harmonia/renderer" in two places. Neither Clap nor PathBuf performs tilde expansion, so at runtime harmonia creates and uses a directory literally named ~ relative to the current working directory rather than the user's home.
Evidence
crates/archon/src/cli.rs:68 — the Clap default for RenderArgs.cert_dir:
#[arg(long, default_value = "~/.config/harmonia/renderer")]
pub(crate) cert_dir: PathBuf,
crates/archon/src/mcp.rs:279 — the MCP call_render fallback uses the same literal:
let cert_dir = optional_path(arguments, "cert_dir")?
.unwrap_or_else(|| PathBuf::from("~/.config/harmonia/renderer"));Both construct a PathBuf whose first component is the literal ~, resolved relative to the process CWD.
Why this matters
A renderer started without an explicit --cert-dir (or via MCP without a cert_dir argument) writes its TLS keypair and pairing credentials into ./~/.config/harmonia/renderer, relative to wherever the process was launched. A later invocation from a different CWD finds no existing cert directory and generates a fresh keypair, silently discarding the prior pairing. Under the counter-surveillance threat model this is doubly harmful: the trust-on-first-use device pairing breaks on every CWD change (so a man-in-the-middle re-pair is indistinguishable from normal operation), and private key material is scattered into stray ~-named directories across the filesystem instead of a single XDG-controlled location with predictable permissions.
Desired correction
Resolve the path through the existing helper dirs_config_path() (already used in crates/archon/src/render/serve.rs:944) or an equivalent dirs::config_dir().join("harmonia/renderer"), and use it as the Clap default via default_value_t/value_parser and as the MCP fallback. Never store an unexpanded ~ in a PathBuf.
Done when: running harmonia render without --cert-dir from two different working directories, and invoking call_render via MCP without cert_dir, all resolve to the same absolute XDG config path, and no directory named ~ is created.
Finding
The renderer's default certificate/credential directory is the literal string
"~/.config/harmonia/renderer"in two places. Neither Clap norPathBufperforms tilde expansion, so at runtime harmonia creates and uses a directory literally named~relative to the current working directory rather than the user's home.Evidence
crates/archon/src/cli.rs:68— the Clap default forRenderArgs.cert_dir:crates/archon/src/mcp.rs:279— the MCPcall_renderfallback uses the same literal:Both construct a
PathBufwhose first component is the literal~, resolved relative to the process CWD.Why this matters
A renderer started without an explicit
--cert-dir(or via MCP without acert_dirargument) writes its TLS keypair and pairing credentials into./~/.config/harmonia/renderer, relative to wherever the process was launched. A later invocation from a different CWD finds no existing cert directory and generates a fresh keypair, silently discarding the prior pairing. Under the counter-surveillance threat model this is doubly harmful: the trust-on-first-use device pairing breaks on every CWD change (so a man-in-the-middle re-pair is indistinguishable from normal operation), and private key material is scattered into stray~-named directories across the filesystem instead of a single XDG-controlled location with predictable permissions.Desired correction
Resolve the path through the existing helper
dirs_config_path()(already used incrates/archon/src/render/serve.rs:944) or an equivalentdirs::config_dir().join("harmonia/renderer"), and use it as the Clap default viadefault_value_t/value_parserand as the MCP fallback. Never store an unexpanded~in aPathBuf.Done when: running
harmonia renderwithout--cert-dirfrom two different working directories, and invokingcall_rendervia MCP withoutcert_dir, all resolve to the same absolute XDG config path, and no directory named~is created.