chore(GRO-720): harden .gitignore against agent runtime leaks #307

$AGENT_HOME/** is a literal string, not an env-var expansion

Git does not perform shell variable expansion in .gitignore patterns. The pattern $AGENT_HOME/** will only match a directory literally named $AGENT_HOME (dollar sign included) — not the path pointed to by the $AGENT_HOME environment variable at runtime. If the agent home is e.g. /home/runner/agent, this rule offers zero protection.

The line immediately above (**/AGENT_HOME/**) already covers a directory named AGENT_HOME at any depth. This pattern is therefore both broken and redundant.

**/AGENT_HOME/**

(Remove the $AGENT_HOME/** line entirely and rely on **/AGENT_HOME/** for recursive coverage, or add the literal expanded path if it is known and constant.)

Prompt To Fix With AI

This is a comment left during a code review.
Path: .gitignore
Line: 21

Comment:
**`$AGENT_HOME/**` is a literal string, not an env-var expansion**

Git does not perform shell variable expansion in `.gitignore` patterns. The pattern `$AGENT_HOME/**` will only match a directory *literally named* `$AGENT_HOME` (dollar sign included) — not the path pointed to by the `$AGENT_HOME` environment variable at runtime. If the agent home is e.g. `/home/runner/agent`, this rule offers zero protection.

The line immediately above (`**/AGENT_HOME/**`) already covers a directory *named* `AGENT_HOME` at any depth. This pattern is therefore both broken and redundant.

```suggestion
**/AGENT_HOME/**
```

(Remove the `$AGENT_HOME/**` line entirely and rely on `**/AGENT_HOME/**` for recursive coverage, or add the literal expanded path if it is known and constant.)

How can I resolve this? If you propose a fix, please make it concise.

<a href="#"><img alt="P1" src="https://greptile-static-assets.s3.amazonaws.com/badges/p1.svg?v=7" align="top"></a> <a href="#"><img alt="security" src="https://greptile-static-assets.s3.amazonaws.com/badges/Security.svg?v=1" align="top"></a> **`$AGENT_HOME/**` is a literal string, not an env-var expansion** Git does not perform shell variable expansion in `.gitignore` patterns. The pattern `$AGENT_HOME/**` will only match a directory *literally named* `$AGENT_HOME` (dollar sign included) — not the path pointed to by the `$AGENT_HOME` environment variable at runtime. If the agent home is e.g. `/home/runner/agent`, this rule offers zero protection. The line immediately above (`**/AGENT_HOME/**`) already covers a directory *named* `AGENT_HOME` at any depth. This pattern is therefore both broken and redundant. ```suggestion **/AGENT_HOME/** ``` (Remove the `$AGENT_HOME/**` line entirely and rely on `**/AGENT_HOME/**` for recursive coverage, or add the literal expanded path if it is known and constant.) <details><summary>Prompt To Fix With AI</summary> `````markdown This is a comment left during a code review. Path: .gitignore Line: 21 Comment: **`$AGENT_HOME/**` is a literal string, not an env-var expansion** Git does not perform shell variable expansion in `.gitignore` patterns. The pattern `$AGENT_HOME/**` will only match a directory *literally named* `$AGENT_HOME` (dollar sign included) — not the path pointed to by the `$AGENT_HOME` environment variable at runtime. If the agent home is e.g. `/home/runner/agent`, this rule offers zero protection. The line immediately above (`**/AGENT_HOME/**`) already covers a directory *named* `AGENT_HOME` at any depth. This pattern is therefore both broken and redundant. ```suggestion **/AGENT_HOME/** ``` (Remove the `$AGENT_HOME/**` line entirely and rely on `**/AGENT_HOME/**` for recursive coverage, or add the literal expanded path if it is known and constant.) How can I resolve this? If you propose a fix, please make it concise. ````` </details>

.gitignore does not retroactively purge committed files from history

The PR description says credentials were "confirmed exfiltrated in commit a407f866." Adding these patterns to .gitignore only prevents future commits of those files — it does not remove data that already exists in git history.

Even though the branch is deleted, commit a407f866 (and any object it references) remains in the repository's object database until it is explicitly removed. Anyone with a clone made before the branch was deleted, or with direct remote access, can still retrieve those objects.

Required follow-up actions:

Rotate all credentials that were committed immediately — GH tokens, any secrets present in the exfiltrated files.
Rewrite history using git filter-repo --path <file> --invert-paths (or BFG Repo Cleaner) to expunge the sensitive files from all branches, then force-push and ask collaborators to re-clone.
Audit the remote (GitHub) to confirm the orphaned commit is not reachable via any ref or cached on GitHub's CDN.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .gitignore
Line: 12-23

Comment:
**`.gitignore` does not retroactively purge committed files from history**

The PR description says credentials were "confirmed exfiltrated in commit `a407f866`." Adding these patterns to `.gitignore` only prevents *future* commits of those files — it does **not** remove data that already exists in git history.

Even though the branch is deleted, commit `a407f866` (and any object it references) remains in the repository's object database until it is explicitly removed. Anyone with a clone made before the branch was deleted, or with direct remote access, can still retrieve those objects.

Required follow-up actions:
1. **Rotate all credentials** that were committed immediately — GH tokens, any secrets present in the exfiltrated files.
2. **Rewrite history** using `git filter-repo --path <file> --invert-paths` (or BFG Repo Cleaner) to expunge the sensitive files from all branches, then force-push and ask collaborators to re-clone.
3. **Audit the remote** (GitHub) to confirm the orphaned commit is not reachable via any ref or cached on GitHub's CDN.

How can I resolve this? If you propose a fix, please make it concise.

<a href="#"><img alt="P1" src="https://greptile-static-assets.s3.amazonaws.com/badges/p1.svg?v=7" align="top"></a> <a href="#"><img alt="security" src="https://greptile-static-assets.s3.amazonaws.com/badges/Security.svg?v=1" align="top"></a> **`.gitignore` does not retroactively purge committed files from history** The PR description says credentials were "confirmed exfiltrated in commit `a407f866`." Adding these patterns to `.gitignore` only prevents *future* commits of those files — it does **not** remove data that already exists in git history. Even though the branch is deleted, commit `a407f866` (and any object it references) remains in the repository's object database until it is explicitly removed. Anyone with a clone made before the branch was deleted, or with direct remote access, can still retrieve those objects. Required follow-up actions: 1. **Rotate all credentials** that were committed immediately — GH tokens, any secrets present in the exfiltrated files. 2. **Rewrite history** using `git filter-repo --path <file> --invert-paths` (or BFG Repo Cleaner) to expunge the sensitive files from all branches, then force-push and ask collaborators to re-clone. 3. **Audit the remote** (GitHub) to confirm the orphaned commit is not reachable via any ref or cached on GitHub's CDN. <details><summary>Prompt To Fix With AI</summary> `````markdown This is a comment left during a code review. Path: .gitignore Line: 12-23 Comment: **`.gitignore` does not retroactively purge committed files from history** The PR description says credentials were "confirmed exfiltrated in commit `a407f866`." Adding these patterns to `.gitignore` only prevents *future* commits of those files — it does **not** remove data that already exists in git history. Even though the branch is deleted, commit `a407f866` (and any object it references) remains in the repository's object database until it is explicitly removed. Anyone with a clone made before the branch was deleted, or with direct remote access, can still retrieve those objects. Required follow-up actions: 1. **Rotate all credentials** that were committed immediately — GH tokens, any secrets present in the exfiltrated files. 2. **Rewrite history** using `git filter-repo --path <file> --invert-paths` (or BFG Repo Cleaner) to expunge the sensitive files from all branches, then force-push and ask collaborators to re-clone. 3. **Audit the remote** (GitHub) to confirm the orphaned commit is not reachable via any ref or cached on GitHub's CDN. How can I resolve this? If you propose a fix, please make it concise. ````` </details>

@@ -8,3 +8,16 @@ dist/
 .turbo/
 coverage/
 minimax-output/
 # Agent runtime artifacts — never commit
 .gh-token
 *.gh-token
 .config/gh/
 **/.config/gh/
 infra-repo/
 infra-repo
 **/instructions/.gh-token
 **/AGENT_HOME/**
 $AGENT_HOME/**
 .claude/
 .codex/