Om Patel's June 15 commit to google-gemini/gemini-cli is small enough to read as maintenance, but its subject is a trust question: when users install a skill, where is the code allowed to land?
The patch, bca5667, changes packages/cli/src/utils/skillUtils.ts so install and link targets are resolved inside the skills directory before copying or symlinking. It rejects traversal-style subpaths and invalid skill names instead of letting path math decide the boundary.
The Human Work
The visible work is not just the guard. The tests read like a checklist from someone closing the escape hatches: .., ., empty names, sibling-directory removal, archive subpaths that leave the temp directory, absolute path names, and traversal names with spaces.
That makes this a maintainer story as much as a security story. Skill systems invite users to bring outside instructions into an agent runtime. Patel's patch says that invitation still needs a hard local folder boundary.
Why It Matters
For agent builders, skill installation is a tempting place to optimize for convenience. The Gemini CLI patch shows the maintenance burden behind that choice: if a skill can be installed from a Git source or archive, the installer also has to defend the destination.
The fair follow-up question for the Gemini CLI thread is practical: was this mainly local filesystem hygiene, or preparation for a larger skill ecosystem where remote sources become routine?
Limits
The evidence does not show an exploited incident, and the article should not imply one. It shows a public prevention patch, a contributor-visible review artifact, and tests that make the boundary harder to regress.