fix(mcp): disclose that Plan Mode read-only status is a server claim

[cybrdude]

Closes #28548.

Summary

Plan Mode presents itself as read-only, and for MCP tools that decision rests on the readOnlyHint annotation the MCP server supplies about itself. Gemini CLI does not verify it, and plan.toml promotes any tool carrying it out of the Plan Mode deny-all into ask_user. A server therefore decides which of its own tools Plan Mode will surface, including a destructive one.

The confirmation prompt still fires, so this is not silent execution. But the prompt never tells the user that the read-only status is a server claim, while Plan Mode's own messaging tells them Plan Mode is read-only. The approval prompt is the control that catches this case, so it should carry the doubt.

Reported to Google VRP as b/524448710 (closed Won't Fix / Infeasible, P2 / S4). Triage confirmed on 2026-07-27 that a public PR is welcome.

What this changes

When an MCP tool is presented for confirmation and the server declared it read-only, the prompt now says so and states that Gemini CLI has not verified the claim. One extra line, shown only when the annotation is present.

• packages/core/src/tools/tools.ts: adds optional serverDeclaredReadOnly to ToolMcpConfirmationDetails.
• packages/core/src/tools/mcp-tool.ts: populates it from the server-supplied readOnlyHint annotation.
• packages/cli/src/ui/components/messages/ToolConfirmationMessage.tsx: renders the disclosure. This mirrors the existing exec redirection-warning pattern, including the extraInfoLines height accounting so the layout math stays correct.
• packages/core/src/tools/mcp-tool.test.ts: asserts the flag tracks the annotation and nothing else (true when declared, false when declared false, false when absent).

What this deliberately does not change

The plan.toml promotion stays. Removing it would deny all MCP tools in Plan Mode and undo the MCP-in-Plan-Mode support from #18229 and the annotation matching from #19671 / #20029 / #20083. No defaults change, no new config surface, no behavior change for servers that do not send the annotation.

Follow-up available on request

Gate the promotion on user-side trust: honor readOnlyHint in Plan Mode only for servers the user has explicitly marked trusted, and treat MCP tools as non-read-only in Plan Mode otherwise. Stronger boundary, but it changes default behavior for existing MCP users, so I kept it out of this PR. Happy to build it if you prefer that shape.

For context, #27156 and #27163 asked for the opposite, trusting readOnlyHint enough to auto-allow annotated tools in Plan Mode, and both were closed. This change is consistent with that outcome.

Testing note

Unit tests are included. I do not have a full local build of the monorepo, so CI here is the first complete typecheck, lint, and test run. Happy to fix up anything it flags.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request improves user security awareness regarding MCP tools by surfacing server-provided read-only claims during the approval process. By clearly distinguishing between a server's declaration and the CLI's verification status, it helps users make more informed decisions when approving tool execution in Plan Mode without altering existing default behaviors or trust models.

Highlights

• Enhanced MCP Tool Transparency: Added a disclosure notice to the tool confirmation prompt when an MCP server marks a tool as read-only, explicitly stating that the claim is unverified by the Gemini CLI.
• Data Flow Updates: Updated the MCP tool invocation logic to capture the readOnlyHint annotation from the server and propagate it through the confirmation details interface.
• Testing: Added unit tests to verify that the serverDeclaredReadOnly flag correctly tracks the server's annotation state.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

📊 PR Size: size/M

• Lines changed: 113
• Additions: +112
• Deletions: -1
• Files changed: 4

[github-actions]

🛑 Action Required: Evaluation Approval

Steering changes have been detected in this PR. To prevent regressions, a maintainer must approve the evaluation run before this PR can be merged.

Maintainers:

1. Go to the Workflow Run Summary.
2. Click the yellow 'Review deployments' button.
3. Select the 'eval-gate' environment and click 'Approve'.

Once approved, the evaluation results will be posted here automatically.

[gemini-code-assist]

Code Review

This pull request adds support for identifying and displaying a warning when an MCP tool is declared as read-only by the server. It updates the ToolConfirmationMessage component to display an unverified read-only claim notice, adds the serverDeclaredReadOnly property to the confirmation details, and includes comprehensive unit tests to verify this behavior. I have no feedback to provide as the implementation is correct and complete.

[gemini-cli]

Hi there! Thank you for your interest in contributing to Gemini CLI.

To ensure we maintain high code quality and focus on our prioritized roadmap, we only guarantee review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'.

This PR will be closed in 7 days if it remains without that designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding.

[cybrdude]

Flagging the 7-day auto-close notice above, since this PR came out of a Google
security triage request rather than the normal backlog.

The finding was reported through the Google VRP as b/524448710. It was closed
Won't Fix (Infeasible), and I asked the triage team whether a PR would be
welcome. On 2026-07-27 they replied: "Sure, you're welcome to submit a PR."
This PR and the linked issue #28548 are the result of that request.

Because of that path, there was no pre-existing "help wanted" issue to attach
to. #28548 is currently labeled status/need-triage and area/security. Could a
maintainer either apply "help wanted" to #28548 or otherwise exempt this from
the auto-close, so it does not lapse before someone can look at it?

On the change itself, in case it helps triage decide quickly:

• Scope is one disclosure line in the MCP tool confirmation, shown only when the
  server sent readOnlyHint. 4 files, +112/-1.
• No default behavior change, no new configuration surface, and no change at all
  for servers that do not send the annotation.
• The Plan Mode policy rule is deliberately untouched, so the MCP-in-Plan-Mode
  support from feat(plan): implement support for MCP servers in Plan mode #18229 and the annotation matching from feat(core): support tool annotations and global wildcards in policies #19671 / feat(policy): Implement Tool Annotation Matching in Policy Engine #20029 / feat(policy): Propagate Tool Annotations for MCP Servers #20083
  all keep working.
• Gemini Code Assist reviewed it and returned no findings.
• No checks are failing. The evaluation workflow is still waiting on maintainer
  approval, so the full suite has not run yet.

If the team would rather take a different shape here, I am happy to adapt it. I
also offered a stronger follow-up in #28548: gate the Plan Mode promotion on
user-side trust rather than only disclosing the claim. I kept that out of this
PR because it changes default behavior for existing MCP users, but I can build
it if that is preferred.

[gemini-cli]

This pull request is being closed as it has been open for 14 days without a 'help wanted' designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding.