[BUG]
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Issue 2 (REC-18): permissions.allow in repo settings does not durably suppress Drive read prompts (cloud/web)
What we configured. The same .claude/settings.json allowlists read-only Drive tools:
json
"permissions": {
"allow": [
"mcp__Google_Drive__read_file_content",
"mcp__Google_Drive__search_files",
"mcp__Google_Drive__list_recent_files",
"mcp__Google_Drive__get_file_metadata",
"mcp__Google_Drive__get_file_permissions"
],
"defaultMode": "default"
}
Expected. With those tools in permissions.allow, Drive reads should proceed without an interactive approval prompt — including in a new session.
Actual. The allowlist does not durably suppress the prompts. Drive read calls (e.g. mcp__Google_Drive__read_file_content) still trigger an interactive permission request. Running /fewer-permission-prompts helps within a session but does not persist to the next session, and the repo-level allow list does not carry over. In the cloud/web UI, a full /permissions command does not appear to be exposed (only /fewer-permission-prompts).
Impact. An interactive read prompt is fatal to an unattended, scheduled routine — there is no human present to approve it, so the run stalls. Our interim workaround is to run the account in Auto permission mode so the classifier approves reads; but that is a blunt instrument (we would prefer read-only tools to be genuinely pre-approved by policy, with writes/sends still gated), and it depends on Auto behaving consistently for scheduled runs.
Ask. Honor permissions.allow from a repo's .claude/settings.json durably across sessions in the cloud/web runtime, so specific read-only MCP tools can be pre-approved without a prompt, while ask/deny entries continue to gate writes and sends. Equivalently: expose a persistent, policy-level allowlist for cloud/web sessions.
What Should Happen?
Issue 2 (REC-18): permissions.allow in repo settings does not durably suppress Drive read prompts (cloud/web)
What we configured. The same .claude/settings.json allowlists read-only Drive tools:
json
"permissions": {
"allow": [
"mcp__Google_Drive__read_file_content",
"mcp__Google_Drive__search_files",
"mcp__Google_Drive__list_recent_files",
"mcp__Google_Drive__get_file_metadata",
"mcp__Google_Drive__get_file_permissions"
],
"defaultMode": "default"
}
Expected. With those tools in permissions.allow, Drive reads should proceed without an interactive approval prompt — including in a new session.
Actual. The allowlist does not durably suppress the prompts. Drive read calls (e.g. mcp__Google_Drive__read_file_content) still trigger an interactive permission request. Running /fewer-permission-prompts helps within a session but does not persist to the next session, and the repo-level allow list does not carry over. In the cloud/web UI, a full /permissions command does not appear to be exposed (only /fewer-permission-prompts).
Impact. An interactive read prompt is fatal to an unattended, scheduled routine — there is no human present to approve it, so the run stalls. Our interim workaround is to run the account in Auto permission mode so the classifier approves reads; but that is a blunt instrument (we would prefer read-only tools to be genuinely pre-approved by policy, with writes/sends still gated), and it depends on Auto behaving consistently for scheduled runs.
Ask. Honor permissions.allow from a repo's .claude/settings.json durably across sessions in the cloud/web runtime, so specific read-only MCP tools can be pre-approved without a prompt, while ask/deny entries continue to gate writes and sends. Equivalently: expose a persistent, policy-level allowlist for cloud/web sessions.
Error Messages/Logs
Steps to Reproduce
Issue 2 (REC-18): permissions.allow in repo settings does not durably suppress Drive read prompts (cloud/web)
What we configured. The same .claude/settings.json allowlists read-only Drive tools:
json
"permissions": {
"allow": [
"mcp__Google_Drive__read_file_content",
"mcp__Google_Drive__search_files",
"mcp__Google_Drive__list_recent_files",
"mcp__Google_Drive__get_file_metadata",
"mcp__Google_Drive__get_file_permissions"
],
"defaultMode": "default"
}
Expected. With those tools in permissions.allow, Drive reads should proceed without an interactive approval prompt — including in a new session.
Actual. The allowlist does not durably suppress the prompts. Drive read calls (e.g. mcp__Google_Drive__read_file_content) still trigger an interactive permission request. Running /fewer-permission-prompts helps within a session but does not persist to the next session, and the repo-level allow list does not carry over. In the cloud/web UI, a full /permissions command does not appear to be exposed (only /fewer-permission-prompts).
Impact. An interactive read prompt is fatal to an unattended, scheduled routine — there is no human present to approve it, so the run stalls. Our interim workaround is to run the account in Auto permission mode so the classifier approves reads; but that is a blunt instrument (we would prefer read-only tools to be genuinely pre-approved by policy, with writes/sends still gated), and it depends on Auto behaving consistently for scheduled runs.
Ask. Honor permissions.allow from a repo's .claude/settings.json durably across sessions in the cloud/web runtime, so specific read-only MCP tools can be pre-approved without a prompt, while ask/deny entries continue to gate writes and sends. Equivalently: expose a persistent, policy-level allowlist for cloud/web sessions.
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.216
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Issue 2 (REC-18): permissions.allow in repo settings does not durably suppress Drive read prompts (cloud/web)
What we configured. The same .claude/settings.json allowlists read-only Drive tools:
json
"permissions": {
"allow": [
"mcp__Google_Drive__read_file_content",
"mcp__Google_Drive__search_files",
"mcp__Google_Drive__list_recent_files",
"mcp__Google_Drive__get_file_metadata",
"mcp__Google_Drive__get_file_permissions"
],
"defaultMode": "default"
}
Expected. With those tools in permissions.allow, Drive reads should proceed without an interactive approval prompt — including in a new session.
Actual. The allowlist does not durably suppress the prompts. Drive read calls (e.g. mcp__Google_Drive__read_file_content) still trigger an interactive permission request. Running /fewer-permission-prompts helps within a session but does not persist to the next session, and the repo-level allow list does not carry over. In the cloud/web UI, a full /permissions command does not appear to be exposed (only /fewer-permission-prompts).
Impact. An interactive read prompt is fatal to an unattended, scheduled routine — there is no human present to approve it, so the run stalls. Our interim workaround is to run the account in Auto permission mode so the classifier approves reads; but that is a blunt instrument (we would prefer read-only tools to be genuinely pre-approved by policy, with writes/sends still gated), and it depends on Auto behaving consistently for scheduled runs.
Ask. Honor permissions.allow from a repo's .claude/settings.json durably across sessions in the cloud/web runtime, so specific read-only MCP tools can be pre-approved without a prompt, while ask/deny entries continue to gate writes and sends. Equivalently: expose a persistent, policy-level allowlist for cloud/web sessions.