Physix Frontier
Running Agents on Unfamiliar Repos: Don't Get Too Comfortable
As someone who has been doing asset allocation for a long time and has seen quite a few tech risk cases, I tried throwing an unfamiliar Git repo at an AI coding agent for project understanding. Conclusion: Not recommended for beginners. An AI coding agent is an assistant that can read code and run commands on your computer; a Git repo is a folder for code versions. You can try it for personal learning if your machine has no keys. But once there are cloud credentials or login keys involved, the risk-reward ratio is terrible. I manage money for a family office, and from an asset allocation perspective, you shouldn't just buy efficiency with tools like this—you need to buy isolation too.
I've been testing a few agent-type tools recently. Since I'm new to LLMs, I didn't dare connect directly to real repos. I created an empty directory in the terminal, manually ran git init, copied the README and a few small files, pretending it was an external repo. The interface showed the agent reading the project structure. I thought the danger point came after I typed "summarize this," but the report says issues like GitSpawn arise because agents run git commands in the background to collect context, sometimes before prompts or workspace-trust popups appear.
Malicious .git config could allow the agent to execute attacker-controlled commands before trust or approval mechanisms take effect.
The bottleneck is "invisibility." The workspace-trust popup asks if you trust the directory, but you can't rely solely on the popup to judge which hooks, aliases, or fsmonitors in the git config will be triggered. The surprise: Even in an isolated environment, the agent still provided file trees and modification plans—the efficiency value is real. But it couldn't give me evidence that the "security boundary" was active.
I lowered permissions: no file writing, no arbitrary command execution, and no cloud credentials. This way, it can only summarize and plan, not auto-fix code. For mature teams, "read-only first, then approval, then execution" is more reliable than relying on popups alone. The report mentions inconsistent statuses for Claude Code, Goose, Qwen Code, Grok Build, and Hermes—some fixed core paths, others haven't patched yet. This shows you can't treat default settings as security guarantees.
From an investment perspective, the moat isn't about whether it can write code, but whether it can turn untrusted inputs into verifiable processes: isolation, least privilege, manual approval, and rollback logs. Whoever can do this with low friction has long-term value. Regular users shouldn't rush to let the agent "act"; let it "look" first.
If you get a repo that looks normal, would you skip clicking the trust confirmation just because "everyone else is using it"?
📌 Compiled from Hacker News, original article: https://www.manifold.security/blog/ai-coding-agents-git-hijack
Copyright belongs to the original authors. This is a compilation and independent analysis based on public reports.
