Run this Git intake checklist before your coding agent touches an untrusted repo

The GitSpawn vector requires the repo to arrive as files with .git intact, such as a shared archive, drive, sync folder, or USB stick, rather than an ordinary clone. A coding agent then runs git status or git diff, and Git executes a helper named in the repo's .git/config core.fsmonitor setting. The operator's job is to stop that execution before the agent touches the repo.

Git config is the intake vector

Manifold Security found eight GitSpawn flaws across seven CLI coding agents; four were unpatched at publication. The exposure is broad enough to require an automated gate, not a warning. Operators should separate repository intake from agent execution before any index-refreshing command runs. Run it before the agent's first command, not after a failure.

Intake needs a gate

The repo enters a staging area before the agent sees it. The staging step checks the repository config, the agent version, and the source of the files. If any check fails, the repo stays out of the agent workspace. The gate runs the same checks for every repo, whether the source is a teammate, a vendor, or a public archive. The gate should be the same for every operator, every machine, and every CI runner.

The staging area should stay outside the agent workspace until the checks pass. The operator or CI job owns the decision to move the repo into the agent workspace. That decision belongs in the intake log.

On developer machines, the gate is local. The operator disables the executable config path, inspects the repository metadata, and confirms the agent build before running the agent. In CI, the gate is a job. The job receives the files, runs the checks, and only then starts the agent. The agent should not have a standing path to the raw archive.

Executable config paths in the metadata trigger quarantine and a source record. Agent builds below the patched release stop the run and require an upgrade. File-based intake stays untrusted until the checks pass.

Keep a short intake log. Record the repo name, source type, agent version, and metadata-check result. The log proves the gate ran and gives a fast way to find the repo that caused a later incident. If the log is missing, treat the run as unverified. The log should be complete enough to audit.

The checklist is the control

Run these checks before the agent runs any index-refreshing command. Each item is testable in a minute.

• Set core.fsmonitor to false in global Git config.
• Open .git/config and look for core.fsmonitor, core.hooksPath, attr.tree, and clean or smudge filter commands.
• Verify the arrival path: files with .git intact, not an ordinary clone.
• Pin the agent to a patched release and record the version before use.
• Do not rely on safe.bareRepository alone.

A failed item stops the run and requires an environment fix before the agent opens the repo. The same order works on a laptop and in CI: disable the helper, inspect the config, verify the arrival path, pin the version, and reject partial safeguards.

Version pins are the last gate

Claude Code's core.fsmonitor issue was reported on June 26 and fixed in version 2.1.196 on June 29. A separate Claude Code route through claude ultrareview remained active, with the behavior verified in version 2.1.252 on September 1. Goose 1.41.0 contained the GitSpawn sink; version 1.44.0 shipped the fix. Codex CLI builds under 0.131.0 were still exposed on September 2, when the current release was 0.152.1.

A build below the patched release stops the agent from opening the repo. An agent that cannot be upgraded runs in a disposable environment, with the repo kept out of the normal workspace.