[BUG] disabled system tools still consume the context

Resolved 💬 6 comments Opened Mar 3, 2026 by nickolay-kondratyev Closed Apr 6, 2026

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?

[Bug] disabledTools in settings.json does not remove tool schemas from context — tokens still consumed

Summary

Tools listed in disabledTools within ~/.claude/settings.json are correctly blocked at execution time, but their schemas are still injected into the system prompt, consuming context tokens as if the tools were fully enabled.

---

Environment

  • Claude Code version: latest (claude-sonnet-4-6)
  • Platform: Linux (Fedora 43)
  • Model: claude-sonnet-4-6
  • Claude Code Version 2.1.63

---

Configuration

~/.claude/settings.json with three tools explicitly disabled:

{
  "disabledTools": ["EnterWorktree", "NotebookEdit", "Skill"]
}

---

Observed Behavior

Despite the above configuration, running /context shows System tools: 11.7k tokens (5.8%) — the full budget, unchanged from a session with no disabled tools.

Furthermore, querying Claude about available tools in-session reveals all three disabled tools are still listed as available in the schema — Claude can see and describe NotebookEdit, EnterWorktree, and Skill in detail, even though invoking them would be blocked.

This means:

  1. The schemas are fully loaded into the context on every session start.
  2. Token cost is identical to having the tools enabled.
  3. The only effect of disabledTools is a runtime execution guard — not a context reduction.

---

Expected Behavior

Tools listed in disabledTools should be excluded from the system prompt entirely — their schemas should not be sent to the model. This would reduce token consumption proportionally to the number and complexity of disabled tools.

---

Why This Is Not a Duplicate of #11370

Issue #11370 reports that disabled MCP servers still load tool definitions and cause invocation errors (No such tool available). That issue is focused on:

  • MCP servers (via disabledMcpServers config)
  • The correctness bug: Claude attempts to call tools that don't exist and gets errors

This issue is distinct:

  • It concerns native system tools (via disabledTools in settings.json), not MCP servers
  • There is no invocation error — the execution guard works correctly
  • The problem is purely token consumption: schemas are loaded and counted against the context budget even when the tools will never be usable

These are separate code paths with separate configs and separate failure modes.

---

Why This Is Not a Duplicate of #17567

Issue #17567 has been closed as a duplicate of #7328, which is scoped to MCP tool filtering and lazy loading of MCP servers. The native disabledTools setting for built-in system tools is not addressed in that chain.

---

Impact

For users who disable tools to reduce context overhead (e.g., to free tokens for larger codebases or longer conversations), the current behavior makes disabledTools effectively useless for that purpose. The only win is preventing accidental tool invocations — not the token savings that are the primary motivation for disabling tools.

---

Suggested Fix

Filter disabled tools before building the system prompt, not only at dispatch time. The disabledTools list should be checked during context construction so that excluded tool schemas are never serialized into the prompt payload.

What Should Happen?

Context of disabled tools should NOT be loaded into context of the agent.

Error Messages/Logs

Steps to Reproduce

  1. disable a tool
  2. run claude
  3. ask if the definition of the tool is loaded and see that /context is unchanged when it comes to system tools

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.63

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗