Please do not open a public issue for a security problem. Use GitHub's private reporting instead:

Report a vulnerability

I will acknowledge within a few days and keep you updated while it is being worked on. If you would rather not use GitHub, email works too.

Field Guide reads repositories, and the whole point of it is to be pointed at one you have not read yourself — the overview tool's own description tells an agent to start there when a codebase is unfamiliar. Two consequences follow, and both have already produced real defects that are now fixed.

A repository is untrusted input, including its configuration. A repository's own .git/config can name commands that git executes. core.fsmonitor is run as a subprocess by git ls-files, so reading a repository was, briefly, running its author's command. It is now pinned off, along with log.showSignature and notes display, and every git invocation passes its configuration with -c rather than inheriting it.

Whatever a tool returns is read by a language model and stays in its context. File paths, module specifiers and author names all come from the repository. A module specifier can carry a newline while looking entirely ordinary in the source, and rendered verbatim it produced a line indistinguishable from one Field Guide wrote — which, for a tool an agent consults before deciding what to trust, is the highest-value thing an attacker could plant. Repository-derived text is now escaped at the render boundary, including the bidirectional overrides that make a string display as something other than what it is.

• Text originating in a repository that reaches a language model's context able to pass as Field Guide's own output, or that displays as something other than what it is
• Anything a repository can put in its files, its names, its history or its .git/config that causes a command to run
• A path escaping the repository, in resolution, in the asset-import fallback, or in the cache
• File contents, credentials, or author email addresses reaching tool output, the extension's log, or anywhere off the machine. Author names are reported by design; email addresses are an identity key and are never rendered
• Any network traffic at all
• A repository that can exhaust memory, disk or CPU without bound. A symlink to a character device reported a size of zero and defeated the file-size guard until it was caught
• Anything reachable in an untrusted VS Code workspace

These are enforced in code and in CI rather than by convention, and a regression in any of them is a bug worth reporting:

• No shell, ever. Every git call goes through one spawn('git', args) with an argument array. There is no exec and no shell: true, so command injection is structurally impossible rather than merely avoided.
• A repository path is never an argument. It is passed as the child's working directory, so a path beginning with - cannot become a flag.
• git runs with its configuration pinned per invocation — core.quotePath, log.showSignature and core.fsmonitor — so a repository cannot change how it is read. Adding -p, --ext-diff or --stat to the history read would open the external-diff and textconv vectors, which are closed today only because those flags are absent.
• Repository-derived text is escaped before rendering, including C0 controls, line separators and bidirectional overrides.
• The analysis imports nothing from the outside world. src/core may not import vscode, Node builtins, or the protocol SDK; a lint rule fails the build otherwise.
• The editor bundle carries no analysis. dist/extension.js is held under 200KB by the build, so the extension host — shared with every other extension the user has installed — never loads a compiler.
• The index runs out of process, so an exhausted heap takes down a child rather than the editor.
• The extension is disabled in untrusted workspaces (untrustedWorkspaces: false), because reading a repository means running git against it.
• No telemetry, no network requests. There is no code in the project that opens a socket.

Field Guide describes a repository; it does not judge it. It is not a security scanner, and a finding that its map is incomplete — a missing edge, an unresolved import — is a correctness bug rather than a vulnerability. The distinction that matters is whether a repository can make Field Guide do something, or say something, that it should not.

The latest published version is the supported one. This is a small project and I do not backport fixes.