Contamination class: a stale GH_CONFIG_DIR inherited from a prior
session or a different agent's workspace caused generate-token.sh to
write .gh-token into a foreign workspace, silently granting that
agent's gh config access to the wrong token.
Three hardening changes:
1. agent-setup/scripts/setup.sh — before deriving GH_CONFIG_DIR from
AGENT_HOME, warn and unset any inherited value that points outside
AGENT_HOME. This prevents the contaminated value from leaking into
the derived path or the dotfile.
2. agent-setup/SKILL.md — correct the sourcing example from `source ~/.env`
to `source "$AGENT_HOME/.env"` so the dotfile is sourced from the
documented location (setup.sh writes to $AGENT_HOME/.env, not ~/
which may differ).
3. github-app-token/scripts/generate-token.sh — (a) add a hard die()
guard that refuses to write the token when GH_CONFIG_DIR is outside
AGENT_HOME; (b) pin GH_CONFIG_DIR="$GH_TOKEN_DIR" on the gh auth
login invocation so it cannot fall back to any inherited config dir.
Verified:
- bash -n passes on both modified scripts
- With GH_CONFIG_DIR=/tmp/someone-elses/.github AGENT_HOME=/tmp/me,
setup.sh warns + overrides; generate-token.sh dies before writing.
- With GH_CONFIG_DIR unset and a valid AGENT_HOME, behaviour is
unchanged (token lands in $AGENT_HOME/.github).
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Gandalf the Greybeard (PE)
5f3f0ab94d