Gemini Worker
v1.0.0Run Gemini CLI as a headless worker agent for long-running or parallelizable tasks. Use when: (1) Anthropic API is overloaded/unavailable (529 errors) and yo...
⭐ 0· 22·0 current·0 all-time
byTrip@cl0ckt0wer
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
Capability signals
These labels describe what authority the skill may exercise. They are separate from suspicious or malicious moderation verdicts.
OpenClaw
Benign
high confidencePurpose & Capability
Name/description, SKILL.md, README, and the included shell wrapper all consistently implement the stated goal: run Google Gemini CLI as a headless worker. The suggested npm install of @google/gemini-cli, the gemini binary usage, and the wrapper script are appropriate and proportional to the described functionality.
Instruction Scope
Instructions legitimately require passing prompts, granting directory access via --include-directories, and auto-approving tool calls with --yolo. Those behaviors are necessary for headless worker use but expand the agent's ability to read/write and have Gemini execute tool calls. SKILL.md does mention prompt-injection risks and gives safer patterns, but the guidance still encourages running with --yolo and absolute include paths — both sensible for the use case but sensitive if misused.
Install Mechanism
No platform-level install spec is provided (instruction-only), which is lower risk. The documentation recommends installing @google/gemini-cli via npm, which is an expected and traceable install for this skill's purpose. No obscure download URLs or extracted archives are present.
Credentials
The skill does not request secrets or external credentials through requires.env. It expects the user to bootstrap OAuth interactively (credentials cached at ~/.gemini/oauth_creds.json) and supports optional GEMINI_TIMEOUT/GEMINI_MODEL env vars in the wrapper script. These are proportionate, though the presence of cached OAuth credentials on disk means the Gemini process will have access to any files you explicitly include.
Persistence & Privilege
always:false and no modifications to other skills or system-wide agent settings. The wrapper will create include directories if missing and relies on the user's cached OAuth file in ~/.gemini — this is normal for a CLI-based worker and not an escalation of platform privileges.
Scan Findings in Context
[base64-block] expected: Found base64-embedded SVG in README (data:image/svg+xml;base64,...). This looks like a benign embedded badge/image and is expected in README files; not an indicator of hidden exfiltration by itself.
Assessment
This skill appears to do exactly what it claims: run Gemini CLI headlessly as a worker. That requires granting the Gemini process explicit read/write access to whatever paths you pass via --include-directories and running with --yolo (auto-approve tool calls). Before installing or using it: 1) Limit --include-directories to the minimal directories needed (avoid including /, your home dir, or other sensitive paths). 2) Do not pass untrusted input directly into -p; prefer writing untrusted content to a file and point Gemini at that file as the docs recommend. 3) Be aware that any file paths you include can be read or written by the Gemini process (and the model can be instructed to run commands via tool calls when --yolo is set). 4) Install @google/gemini-cli only from the official npm package and verify provenance if possible. 5) Consider running the worker in an isolated environment (container, CI runner, or dedicated service account) if you will include project or system directories. If you want stronger assurance, ask the maintainer for a homepage or repository signature, or request a signed release link so you can verify the upstream source.Like a lobster shell, security has layers — review code before you run it.
latestvk97e0th9v5cwmnpbwp231mr4g584bzjf
License
MIT-0
Free to use, modify, and redistribute. No attribution required.