[FEATURE]: opt-in visibility of git-ignored files (.env, project configs) in session Review/diff #56121

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

OpenCode's session snapshot/diff pipeline deliberately excludes every path that the source repository ignores (via .gitignore, .git/info/exclude, global ignores). This is hardcoded and not configurable:

• snapshot capture lists files with git ls-files --others --exclude-standard and drops ignored candidates from the index (packages/core/src/git.ts, updateIndex / Git.index.ignored);
• Snapshot.files() and Snapshot.diff() additionally filter results through git check-ignore --no-index against the source repo — "the source repository's ignore rules decide what callers see" (packages/core/src/snapshot.ts).

The consequence: when the agent edits files that are commonly git-ignored — .env, .opencode/ configs (many teams gitignore this directory, see #4565), lockfiles, local settings — the changes are completely invisible in the desktop app's Review pane. There is no diff, no entry in the file list, and therefore no way to inspect, accept, or revert those edits from the UI. The user only sees the tool call in the chat, not the actual change.

This creates a real blind spot precisely around the most sensitive files in a project (secrets, environment config, agent configuration): the one place designed for human review of agent edits is exactly where these edits disappear.

Proposed solution

An opt-in way to see changes to ignored files in the session Review pane. Two levels, either would already help:

1. Minimum — make invisibility explicit: when ignored files were modified between two snapshots, show a non-interactive notice in the Review pane, e.g. "2 ignored files changed (.env, .opencode/opencode.jsonc) — hidden". Today the pane simply shows "no changes", which silently misleads the user into thinking the agent didn't touch anything.

2. Full — opt-in display: a config option (default false, per-project), e.g.:

   { "snapshot": { "include_ignored": true } }

   When enabled, Git.index.ignored() / Snapshot.files() / Snapshot.diff() stop dropping those paths (or a separate ignore list is used for snapshot scoping instead of the raw VCS rules), so ignored-file edits get the same diff view and review workflow as everything else.

I'd suggest scoping the first iteration to display and diffing only. Including ignored files in restore/undo/revert is a separate decision — I understand #28033 and #53560 make bulk operations over ignored paths a deliberate safety measure, and that concern is legitimate. Display-only review does not conflict with it: one can show the diff while leaving revert semantics unchanged (or gating revert of ignored files behind an explicit confirmation).

Why this is useful

• Transparency / auditability: the Review pane is the core safety mechanism of an agentic IDE ("look at what the agent changed before accepting"). Files matching .gitignore are not less likely to be edited by an agent — .env is one of the most frequently edited files in real projects.
• Security: today an agent can silently modify secrets/env configuration with zero trace in the review UI. Showing the diff makes accidental or malicious credential changes visible.
• Consistency with peers: Cursor shows agent edits to git-ignored files (including .env) in its review/accept UI by default, and it works well in practice — ignored-ness is a property of VCS tracking, not of "should the human see this change". Other tools that track changes by file-content snapshot rather than by git semantics (e.g. Claude Code's file checkpoints) similarly do not hide .gitignored files.
• Low cost: the change is already on disk and captured by the worktree; the filtering is a single choke point (ignored() in snapshot.ts + candidate filtering in git.ts), so an opt-in flag is a contained change.

Additional context

Related but distinct issues: #28033 (ignored files leaking into undo/revert — closed as a bug, i.e. filtering is intentional; this request does not ask to change restore semantics by default), #4565 (whether .opencode/ should be gitignored at all — today gitignoring it has the side effect of hiding its changes from Review), #45911 (glob not matching dotfiles — tool-level, not diff-level).