Google’s Gemini CLI repository has added a caretaker triage worker for GitHub issues. Its most revealing choice is not a model name. The agent is started with a deny-all tool policy and a short list of permissions to view files, list directories, find files, search directories, activate local skills, and finish. It can inspect a codebase; it is not given a tool to patch it, run a shell command, or post to GitHub.
That is a useful line for a maintainer team to draw. An issue classifier can produce a proposed diagnosis, an effort estimate, and a workable specification without being the thing that changes the repository.
The newly added worker puts the next step somewhere plainer: it claims an issue lock, parses and validates the model’s JSON, then routes the result. Spam, empty reports, and feature requests receive an auto-close label; a report needing details gets a comment; a workable report gets an effort label and stored specification. A failure releases the lock for retry or human handling.
The boundary is real, but it is not the whole safety story
The code’s architecture matters because it separates two kinds of authority. The model can explore source material and return a structured opinion. The worker owns the outward effects, and it only reaches them after a validator accepts that opinion. The integration tests also make the intended failure shape visible: invalid output returns an issue to an untriaged state, and repeated attempts eventually produce a NEEDS_HUMAN outcome.
But the first, flattering reading of this design—that a read-only model is simply “safe”—does not survive the nearby files. The model’s system instructions say an issue body will arrive inside <untrusted_context> tags and must never be treated as an instruction. The current prompt builder, however, assembles the issue title and description as ordinary labeled text. The tool allow-list still limits what the agent can do, but the promised delimiter is not visible in the assembled prompt. And the surrounding worker can still turn a bad but valid-looking classification into a public label or comment.
A maintenance assistant should leave a receipt, not a mystery
The lesson is not that agents must be silent. It is that the answer to “what may this model do?” should differ from the answer to “what may this service do after checking the model?” The caretaker’s resolved run can be logged, its response is narrowed to a final structured output, and its state transitions are explicit enough to test. Those are better ingredients for an issue assistant than a single all-powerful automation loop.
This commit proves an implementation and mocked integration tests, not a deployed Cloud Run job, triage accuracy, or a reduction in maintainer burden. The next public signal that would change the story is a deployment or end-to-end test showing the real SDK and egress path, together with a prompt assembly that actually wraps untrusted issue text the way its own instructions require.