Skip to content

RFC: Feature Configuration Service — Read/Write Scope-Based Feature Toggles #255

Description

@allenhutchison

Summary

We need a configuration mechanism to let users control which services and scopes the extension requests. This solves two problems:

  1. Contributor PRs that need new scopes — PRs like feat(tasks): add support for Google Tasks #106 (Google Tasks), fix(slides): enable reliable Slides tool usage and write operations #237/feat(slides): add write tools for Google Slides #235 (Slides write), and Feat sheets insert text  #233 (Sheets write) add features requiring scopes that aren't enabled in the published GCP project. Contributors should be able to develop and test these features with their own GCP projects, while the features remain opt-in for other users.

  2. Users want scope control — Issue Gemini CLI Workspace Extension wants additional access to your Google Account #86: users who only need a few services don't want to auth for all scopes. Issue Feature Request: Add Support for Customizable OAuth Scopes to Prevent Unintended Email Operations #111: users want to restrict Gmail to read-only to prevent accidental sends.

Proposed Design: Read/Write Feature Groups

Each service is split into read and write groups. Read groups have no side effects and use readonly scopes. Write groups perform mutations and require elevated scopes.

Service Group Scopes Default
docs read documents ✅ ON
docs write documents, drive ✅ ON
drive read drive.readonly ✅ ON
drive write drive ✅ ON
calendar read calendar.readonly ✅ ON
calendar write calendar ✅ ON
chat read chat.spaces.readonly, chat.messages.readonly, chat.memberships.readonly ✅ ON
chat write chat.spaces, chat.messages, chat.memberships ✅ ON
gmail read gmail.readonly ✅ ON
gmail write gmail.modify ✅ ON
people read userinfo.profile, directory.readonly ✅ ON
slides read presentations.readonly ✅ ON
slides write presentations ❌ OFF
sheets read spreadsheets.readonly ✅ ON
sheets write spreadsheets ❌ OFF
time read (none) ✅ ON
tasks read tasks.readonly ❌ OFF
tasks write tasks ❌ OFF

Key points:

  • Services whose write scopes aren't in the published GCP project (Slides write, Sheets write, Tasks) default to OFF
  • Disabling a write group keeps the read tools available
  • Auth tools (auth.clear, auth.refreshToken) are always registered

Configuration via Environment Variables

# Disable specific feature groups (even if default ON)
WORKSPACE_DISABLED_FEATURES=gmail.write,chat.write

# Enable experimental feature groups (default OFF)
WORKSPACE_ENABLED_FEATURES=slides.write,tasks.read,tasks.write

Rules:

  1. WORKSPACE_DISABLED_FEATURES takes precedence — disables even default-ON features
  2. WORKSPACE_ENABLED_FEATURES enables default-OFF features
  3. Disabling a feature group removes both its tools and its OAuth scopes
  4. Re-enabling a previously disabled feature may require re-auth for the new scope

Impact on Contributors

Contributors adding new services would:

  1. Define read and write feature group entries in the feature config registry
  2. Set their default state (ON for scopes in the published project, OFF otherwise)
  3. Gate their tool registrations on the feature config

This lets contributors develop and merge new features without being blocked by the published GCP project's scope configuration.

Questions for the Community

  1. Is the read/write split the right granularity? Or would you prefer per-tool toggles?
  2. Are environment variables sufficient for configuration, or would you also want a config file?
  3. Are there other services or scopes you'd like to see supported?

Related Issues & PRs

Activity

  1. Jefftree commented on Mar 3, 2026

    @Jefftree
    Contributor

    one feedback: Why not unify into one list since things are already defaulted? WORKSPACE_FEATURE_OVERRIDES="gmail.write:off,slides.write:on".
    The read/write split seems sensible.

  2. raybell-md commented on Mar 3, 2026

    @raybell-md
    Contributor

    LGTM.

    Is the read/write split the right granularity? Or would you prefer per-tool toggles?

    Read and write make sense. I assume there will be more ❌ OFF with new defaults at the end of this? If read-only scope are defaults it may help myself and others get this extension added to our google auth allow list. (note: it's currently approved for me as I'm in my own OU). However, I would like to use this tool as a power user and give it full permission to google workspace to maximize it's potential. Why else would I use a workspace MCP server :). Then users could add allows tools and disallow tools in Gemini CLI. Worth noting there are other tools (#196 (comment))

    Are there other services or scopes you'd like to see supported?

    May as well add keep to the list above (#159)

  3. bdoyle0182 commented on Mar 3, 2026

    @bdoyle0182

    Enterprise user here, per tool toggles would be required for us to onboard. Specifically on disabling delete tools, but not other types of writes.

  4. allenhutchison commented on Mar 5, 2026

    @allenhutchison
    ContributorAuthor

    Thanks for the great feedback everyone! Here's how we're incorporating it:

    @Jefftree — Love the unified env var idea. We're adopting WORKSPACE_FEATURE_OVERRIDES with your feature:on/off syntax as the power-user configuration layer.

    @bdoyle0182 — We're extending the override syntax to support per-tool toggles (subtractive only from enabled groups):

    WORKSPACE_FEATURE_OVERRIDES="calendar.deleteEvent:off,gmail.send:off"
    

    This lets you keep calendar.write enabled while disabling specific destructive tools.

    @raybell-md — Google Keep added to the roadmap. Good point about the enterprise allowlist — defaulting to readonly scopes will help there. We're keeping writes default-ON for now to avoid breaking existing users, but the settings UI makes it easy to turn them off.

    Updated Design: Three-Layer Configuration

    1. Install-time UI (via gemini-extension.json settings) — Per-service read/write toggles shown during gemini extensions install. Users check off which services they want without touching env vars.

    2. Power-user overrides — WORKSPACE_FEATURE_OVERRIDES env var with group-level (gmail.write:off) and tool-level (calendar.deleteEvent:off) syntax.

    3. Baked-in defaults — Current services default ON, future/experimental services (Tasks, Slides write, Sheets write) default OFF.

    Precedence: Power-user overrides > Settings UI > Defaults

    This gives most users a clean install experience while giving enterprise and power users the fine-grained control they need.

  5. added 4 commits that reference this issue on Mar 20, 2026
    71f76cf
    801506c
    4ff43b0
    5174e33
  6. chriscoey commented on Mar 28, 2026

    @chriscoey

    This would be really valuable for MCP clients like Claude Code that already have managed connectors for Gmail and Calendar. Without service filtering, adding this server means ~35 duplicate/unused tools in the deferred tool list alongside the ~20 we actually need (Drive, Docs, Sheets, Slides).

    The env var approach in the RFC looks great. Even a simpler first pass — just disabling entire services via something like WORKSPACE_SERVICES=drive,docs,sheets,slides — would unblock adoption for a lot of us. Happy to help test if a branch lands.

  7. added a commit that references this issue on Apr 1, 2026
    48ebe1e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions