astrid init writes a PATH line into the user's real shell rc for every non-default ASTRID_HOME

[joshuajbouw]

Summary

astrid init unconditionally appends an # Astrid OS + export PATH="<home>/bin:$PATH" block to the user's real ~/.zshrc — including when ASTRID_HOME points at a temporary or isolated home. The append guard keys on the exact path, so every distinct home appends a new block.

Observed on a real workstation: six accumulated # Astrid OS PATH blocks in ~/.zshrc, five pointing at long-dead temp dirs ($TMPDIR/…, session scratchpads) from isolated-home test runs, one legitimate (~/.astrid/bin).

Impact

• Dead PATH entries accumulate silently in the operator's shell rc (harmless to resolution, but real pollution of a file users care about).
• Any tooling that runs astrid init in an isolated ASTRID_HOME (e2e suites, the installer's own verification, CI) mutates operator state outside the home it was told to use — surprising for a runtime whose stance is fail-closed isolation.

Expected

One (or more) of:

• Only append when the target is the default resolved home (~/.astrid), never for an ASTRID_HOME override;
• and/or dedupe on the # Astrid OS marker (replace the block) instead of exact-path grep;
• and/or an explicit --no-profile / respect a ASTRID_NO_PROFILE env for automation.

Fail-secure default: an isolated home should leave zero footprint outside itself.

[joshuajbouw]

Confirmed current. Successful init still unconditionally calls ensure_path_setup, which derives the active Astrid home bin path and may append it to the real user shell rc. The dedupe is path-specific and there is no ASTRID_HOME-override guard or automation opt-out, so distinct temporary homes still accumulate blocks.