1. 那条反复弹出的提示到底在说什么如果你最近在终端里跑 Claude Code大概率见过这么一条提示were changing auto mode to no longer charge for classifier requests。它会在你每次启动会话、或者隔一段时间就冒出来一次像极了那种关不掉的系统更新弹窗。很多人第一反应是我是不是哪里配置错了然后开始翻文档、查环境变量折腾半天发现根本没用——因为这条提示本身不是错误而是产品侧的一个变更通知。先把事情说清楚。Claude Code 的 auto mode 里有一个叫 classifier 的组件它的作用是判断当前这个请求该走哪条路径、要不要触发自动决策逻辑。早期这个 classifier 的调用是计入用量成本的后来官方调整策略classifier requests 不再单独计费。为了告知用户这个变化客户端会在会话里推送这条通知。问题在于这个通知的触发逻辑比较激进导致它在很多场景下反复出现干扰了正常的命令行工作流。这条提示的核心关键词有三个auto mode、classifier requests、免费。auto mode 是 Claude Code 的一种运行模式开启后它会自动判断任务类型并选择合适的处理方式不需要你每次手动指定。classifier requests 指的是 auto mode 内部用来做请求分类的那些调用。免费则是指这部分调用不再产生额外费用。三者串起来就是auto mode 下的分类请求现在不收费了客户端在通知你这个事。那为什么它会反复出现这就要说到客户端的通知机制了。根据实际观察这条提示的展示逻辑和会话状态、配置读取、以及本地缓存都有关系。如果你的配置文件里没有明确记录已读状态或者环境变量没有正确传递客户端每次启动都会认为你是第一次看到这个通知于是再弹一遍。这不是 bug而是通知去重机制在特定配置下失效的表现。适合读这篇内容的人很明确已经在用 Claude Code、被这条提示烦到、想彻底关掉它的人。如果你还没装 Claude Code这篇也能帮你提前理解它的配置体系避免以后踩同样的坑。下面我会从提示的触发原理讲起然后给出几种不同层级的关闭方案最后说说我在实操中遇到的几个意外情况。2. 通知反复触发的三个真实原因2.1 配置状态没有持久化到本地Claude Code 的很多行为依赖本地配置文件最典型的就是settings.json。这个文件通常位于用户目录下的配置文件夹里记录着你的偏好设置、已读通知、功能开关等信息。当客户端推送那条 classifier 通知时它会在本地写一个标记表示这个通知用户已经看过了。下次启动时先读这个标记有标记就不再弹。问题出在写入环节。如果你的settings.json所在目录权限不对或者文件被其他进程占用写入就会失败。写入失败但客户端不报错只是默默地在下次启动时重新弹通知。我遇到过一种情况配置文件被同步工具锁定了每次写入都被拦截导致通知连续弹了十几次。排查的时候可以看一下配置文件的修改时间如果它一直不更新基本就是写入被阻断了。还有一种更隐蔽的情况你用了多个终端会话或者在不同的工作目录下启动 Claude Code。如果客户端把状态写在了项目级的配置里而不是用户级的配置里那么换个目录启动就会重新弹。这种设计在多人协作场景下有一定道理但对个人用户来说就是纯粹的干扰。2.2 环境变量没有正确传递CLAUDE_CODE_AUTO_MODE_SERVER这个环境变量是控制 auto mode 服务端行为的关键开关。它的值决定了客户端在启动时如何初始化 auto mode 相关的逻辑包括是否检查通知状态、是否走服务端下发的配置。如果你在 shell 里临时 export 了这个变量但没有写进 shell 的启动脚本比如.bashrc、.zshrc或 Windows 的环境变量设置那么新开的终端会话就读不到它。读不到的时候客户端会走默认逻辑而默认逻辑里通知检查是开启的。这就解释了为什么有些人明明设置过了但重启终端后提示又回来了。环境变量的作用域是个容易被忽略的点。在 Linux 和 macOS 上你在当前终端 export 的变量只对当前会话和它的子进程有效。关掉终端就没了。在 Windows 上通过命令行 set 设置的变量也是临时的只有通过系统属性面板或者 setx 命令设置的才是持久的。很多人卡在这一步以为设置完了其实只是当前窗口有效。2.3 客户端版本与通知逻辑的错配Claude Code 更新比较频繁不同版本对通知的处理逻辑有差异。有些版本里通知的去重依赖服务端返回的一个状态字段有些版本里这个逻辑改成了纯本地判断。如果你用的版本正好处于逻辑切换的过渡期就可能出现本地以为该弹、服务端以为不该弹的错配。这种情况的典型表现是你按照旧版本的教程改了配置但新版本已经不读那个配置项了于是提示照弹不误。反过来也一样新版本的配置项在旧版本里不存在改了也没用。判断方法很简单跑一下claude --version看当前版本号然后对照官方更新日志里关于 auto mode 和 classifier 的条目。如果日志里提到通知逻辑有变更那基本就是版本错配的问题。提示不要盲目照搬网上搜到的配置片段。Claude Code 的配置项在不同版本间有增删先确认版本再动手能省掉大量无效折腾。这三个原因经常是叠加出现的。比如你环境变量没设对同时配置文件又没写权限那通知就会以各种你意想不到的方式反复出现。排查的时候建议按先看配置文件、再看环境变量、最后看版本的顺序来从最容易被忽略的地方入手。3. 从配置层彻底关掉这条提示3.1 修改 settings.json 的正确姿势最直接的办法是在settings.json里显式关闭这个通知。这个文件的位置因系统而异Linux 和 macOS 通常在~/.config/claude-code/settings.json或者~/.claude/settings.jsonWindows 在%APPDATA%\claude-code\settings.json。如果你不确定具体路径可以在 Claude Code 里执行一个查看配置的命令或者直接搜一下用户目录下叫 settings.json 的文件。打开文件后你需要关注的是和 auto mode、notification 相关的字段。根据实际配置经验通常需要设置类似这样的结构{ autoMode: { classifierNotification: false, showUpgradePrompts: false }, notifications: { dismissed: [auto_mode_classifier_free] } }这里解释一下每个字段的意图。classifierNotification控制是否展示 classifier 相关的通知设为 false 就是直接关掉。showUpgradePrompts控制升级提示因为这条通知有时候和版本升级提示是绑在一起推的一起关掉更干净。dismissed数组里记录已经关闭过的通知 ID把 classifier 那条的 ID 加进去客户端下次检查时就会跳过。改完之后有个关键动作确认文件真的被保存了。我见过有人用编辑器改完没保存就重启然后说配置没用。另外如果文件里已经有其他配置注意 JSON 的语法多一个逗号少一个引号都会导致整个文件解析失败客户端会回退到默认配置通知照弹。改完可以用python -m json.tool settings.json验证一下语法。3.2 环境变量的持久化设置CLAUDE_CODE_AUTO_MODE_SERVER这个变量的设置方式取决于你的操作系统和 shell。它的作用是指定 auto mode 服务端的地址或行为模式间接影响通知的拉取逻辑。把它设成一个明确的值可以避免客户端走默认的检查流程。在 Linux 和 macOS 上如果你用的是 bash编辑~/.bashrc用 zsh 就编辑~/.zshrc。在文件末尾加上export CLAUDE_CODE_AUTO_MODE_SERVERlocal然后执行source ~/.bashrc或source ~/.zshrc让配置立即生效。验证方法是新开一个终端跑echo $CLAUDE_CODE_AUTO_MODE_SERVER能打印出 local 就说明设置成功了。Windows 用户分两种情况。如果你用 PowerShell可以执行[Environment]::SetEnvironmentVariable(CLAUDE_CODE_AUTO_MODE_SERVER, local, User)这条命令会把变量写到用户级环境变量里重启终端后生效。如果你用 CMD用setx CLAUDE_CODE_AUTO_MODE_SERVER local效果一样。注意 setx 设置完后当前窗口不会立即生效需要新开一个窗口。注意环境变量的值不要随便填。local表示走本地逻辑不依赖服务端下发配置这是关闭通知最稳妥的方式。填其他值可能触发不同的行为分支反而让问题更复杂。3.3 配置文件与环境变量的优先级关系这里有个很多人搞混的点配置文件和环境变量同时存在时谁说了算根据实际测试Claude Code 的读取顺序是环境变量优先于配置文件。也就是说如果你在 settings.json 里关了通知但环境变量里有个值强制开启了服务端检查那通知还是会弹。这个优先级设计有它的道理环境变量适合做临时覆盖和不同环境下的差异化配置配置文件适合做长期偏好。但对我们来说意味着两处都要设置正确不能只改一处。我建议的做法是配置文件里做完整的关闭设置环境变量里设一个明确的值来固化行为两者配合基本可以杜绝反复弹窗。如果你在团队环境里用 Claude Code还要注意项目级配置和用户级配置的覆盖关系。项目级的 settings.json 如果存在会覆盖用户级的部分设置。检查一下你的项目根目录下有没有.claude/settings.json之类的文件有的话也要同步修改。4. 不同系统下的实操差异与验证4.1 Linux 和 macOS 的完整操作链路在 Linux 和 macOS 上整个操作可以串成一条清晰的链路。先定位配置文件用ls -la ~/.config/claude-code/或ls -la ~/.claude/看看文件在不在、权限对不对。权限建议是 644也就是你自己可读写其他人只读。如果权限是 600 或者更严格一般也没问题但如果是 root 拥有的文件而你用普通用户跑 Claude Code写入就会失败。然后编辑配置文件加上前面说的那些字段。保存后用cat或者jq确认内容正确。接着设置环境变量写进 shell 启动脚本。最后新开一个终端跑一次 Claude Code观察通知是否还出现。验证的时候有个小技巧先故意不改配置启动一次记下通知出现的时间点。然后改完配置再启动对比两次的行为。如果第二次启动后通知没出现而且持续用了几分钟也没弹基本就成功了。如果还弹检查一下是不是有多个配置文件、或者环境变量没生效。macOS 上还有个特殊情况如果你用 Homebrew 装的 Node环境变量的加载路径可能和系统自带的不一样。确认一下你的 shell 启动脚本是不是被正确加载了可以在脚本里加一行echo shell config loaded启动终端时看看有没有输出。4.2 Windows 下的路径与权限坑Windows 的配置路径和权限模型跟 Unix 系差别很大坑也更多。配置文件通常在%APPDATA%\claude-code\settings.json这个路径可以用echo %APPDATA%在 CMD 里查看或者在 PowerShell 里用$env:APPDATA。权限方面Windows 的用户目录一般不会有写入问题但如果你把 Claude Code 装在系统级目录下或者用管理员权限装过什么东西可能导致配置文件的所有者变成管理员账户普通用户写入被拒。检查方法是右键文件看属性里的安全选项卡确认你的用户账户有写入权限。环境变量在 Windows 上要特别注意用户变量和系统变量的区别。用户变量只对当前用户生效系统变量对所有用户生效。个人使用设用户变量就够了设系统变量反而可能影响其他账户。设置完之后一定要新开一个 CMD 或 PowerShell 窗口验证老窗口读的是旧的环境变量快照。还有一个 Windows 特有的问题如果你同时装了 WSL 和 Windows 原生版 Claude Code两者的配置是独立的。在 WSL 里改的配置不会影响 Windows 原生版反之亦然。搞清楚你平时用的是哪个别改错了地方。4.3 验证关闭效果的三种方法改完配置不能只看这次没弹要确认是持久生效的。我常用三种验证方法组合起来基本能覆盖所有情况。第一种是重启验证。完全关掉所有终端窗口重新打开启动 Claude Code观察前几分钟有没有通知。这是最基础的验证能排除临时状态的影响。第二种是多会话验证。同时开两三个终端分别在不同目录下启动 Claude Code。如果通知只在某个目录下出现说明是项目级配置的问题如果都不出现说明用户级配置生效了。第三种是版本升级后验证。Claude Code 升级后配置项有可能被重置或者新增检查逻辑。升级完先跑一次看通知有没有回来。如果回来了对照更新日志看看是不是新增了配置项补上就行。验证方法操作要点能发现的问题重启验证关闭所有终端后重新启动临时状态干扰、环境变量未持久化多会话验证不同目录同时启动多个实例项目级配置覆盖、路径相关问题升级后验证版本更新后立即测试配置项失效、新增检查逻辑这三种方法我一般会在改完配置后一次性跑完虽然多花几分钟但能避免以为关掉了结果过两天又弹的尴尬。5. 那些文档里不会写的踩坑记录5.1 配置文件被同步工具锁定的排查过程前面提到过配置文件写入失败的情况这里展开说一个我实际遇到的案例。当时我在一台开发机上改完 settings.json重启 Claude Code通知还在。反复检查配置内容语法没问题路径也对。后来用stat命令看文件的修改时间发现它停留在几天前也就是说我的修改根本没写进去。进一步排查发现这台机器上装了一个文件同步工具它会监控配置目录任何写入都会被它拦截并尝试同步到远端。同步过程中文件被锁定Claude Code 的写入操作就失败了。解决办法是把配置目录加入同步工具的排除列表或者临时暂停同步再改配置。这个坑的隐蔽之处在于编辑器里看文件内容是对的因为编辑器读的是缓存或者同步下来的版本但实际磁盘上的文件没变。判断方法是改完配置后用命令行cat一下看内容是不是真的更新了。如果编辑器显示的和命令行显示的不一致基本就是同步工具在捣鬼。5.2 多版本共存导致的配置混乱有些人机器上同时装了多个版本的 Claude Code比如一个通过 npm 全局装的一个通过其他包管理器装的还有一个是手动下载的。这些版本可能读不同的配置文件或者读同一个文件但解析逻辑不同。我遇到过的情况是npm 版读~/.claude/settings.json手动安装版读~/.config/claude-code/settings.json。我只改了其中一个结果用另一个版本启动时通知照弹。排查的时候用which claude看当前用的是哪个可执行文件然后顺着它的安装路径找配置文件。多版本共存的另一个问题是环境变量。不同版本可能对同一个环境变量有不同的解释。比如CLAUDE_CODE_AUTO_MODE_SERVER在旧版本里可能只接受特定几个值新版本里接受任意字符串。如果你在旧版本里设了一个新版本才支持的值旧版本可能直接忽略走默认逻辑。提示如果你不确定自己装了几个版本用which -a claudeLinux/macOS或where claudeWindows列出所有可执行文件路径逐个确认。5.3 通知关闭后功能受影响的边界关掉通知本身是安全的但要注意别把相关的功能开关一起关了。有些配置项是通知和功能绑定的关通知的同时会把功能也禁用。比如 auto mode 的某些自动决策逻辑如果它的开关和通知开关是同一个字段关了之后 auto mode 可能就不自动了变成每次都要手动指定。判断方法是关掉通知后实际跑几个任务看 auto mode 的行为有没有变化。如果发现它不再自动选择处理路径了说明关过头了需要把功能开关单独打开。理想的做法是找到只控制通知展示的那个字段而不是控制整个 auto mode 的字段。从我的经验看classifierNotification这类字段通常只影响展示层不会动到核心逻辑。但autoMode下的一些其他字段就不好说了改之前最好备份一下配置文件出问题能快速回滚。6. 让配置长期稳定的几个习惯6.1 把配置纳入版本管理配置文件改来改去时间长了容易忘记改过什么。我的做法是把settings.json纳入个人 dotfiles 仓库用 git 管理。每次修改都提交一次写清楚改了什么、为什么改。这样出问题的时候可以快速对比历史版本也能在新机器上快速恢复配置。具体操作是在 dotfiles 仓库里建一个 claude-code 目录把配置文件软链接过去或者写一个安装脚本在部署时复制过去。软链接的好处是改一处两边同步坏处是某些系统对软链接的支持不一致。复制的方式更稳妥但需要记得改完源文件后重新部署。环境变量的设置也可以写进 dotfiles 的 shell 配置里和配置文件一起管理。这样换机器的时候clone 仓库、跑一下安装脚本环境和配置就都齐了。6.2 升级前先备份配置Claude Code 升级有可能重置或迁移配置。虽然大多数时候升级是平滑的但涉及配置结构变更的版本升级过程可能会覆盖你的自定义设置。养成升级前备份的习惯能省掉很多麻烦。备份很简单把配置文件和 shell 配置里相关的行复制一份加上日期后缀。升级完对比一下看有没有被改动。如果被改了把备份里的自定义部分合并回去。这个操作花不了一分钟但能在出问题时救急。6.3 关注官方更新日志里的配置变更Claude Code 的更新日志里会提到配置项的增删改。养成升级后扫一眼日志的习惯重点看和 auto mode、notification、环境变量相关的条目。如果日志里说某个配置项废弃了或者新增了及时调整自己的配置避免用着废弃的字段还以为生效了。日志里如果提到通知逻辑优化之类的描述更要留意因为这往往意味着通知的触发条件变了原来的关闭方法可能失效。这时候需要重新测试找到新的关闭方式。7. 关于这条提示的几个常见误解7.1 这不是错误是产品变更通知很多人看到提示反复出现第一反应是是不是我哪里配错了。其实这条提示本身是正常的产品变更通知不是错误信息。它的目的是告知用户 classifier requests 不再收费属于信息传达不是故障报警。理解这一点很重要能避免你在错误的方向上排查。当然通知反复出现确实是个体验问题但它的根源是通知去重机制在特定配置下失效而不是你的环境坏了。所以解决思路应该是调整配置让去重生效而不是修复某个损坏的东西。7.2 关闭通知不影响正常使用有人担心关掉通知会不会影响 auto mode 的功能或者导致某些请求走错路径。从实际使用来看关闭通知只影响展示层不影响 classifier 的实际工作。classifier 该跑还是跑该分类还是分类只是不再弹那条提示了。如果你实在不放心可以在关闭通知后跑几个不同类型的任务观察 auto mode 的选择结果和之前有没有差异。我测试下来是没有差异的auto mode 的行为完全一致。7.3 免费不等于无限制提示里说的免费是指 classifier requests 不再单独计费但不代表整个 Claude Code 的使用完全免费。其他类型的请求、超出配额的部分该计费还是计费。别看到免费两个字就以为可以随便用具体还是要看你的订阅方案和用量情况。这个区分很重要因为有些人可能会误解提示的含义以为所有请求都免费了。实际上只是 classifier 这一块的计费策略调整其他部分不变。8. 我在实际配置中总结的几条经验折腾这条提示的过程中我积累了几个比较实用的经验分享出来供参考。第一改配置前先确认当前生效的配置文件路径。不同安装方式、不同版本读的文件可能不一样盲目改一个可能根本没被读取。用claude --version和which claude确认版本和路径再顺着找配置文件比到处乱改高效得多。第二环境变量和配置文件要一起改。只改一个往往不够因为两者的优先级和生效范围不同。环境变量管当前会话和子进程配置文件管长期偏好配合使用才能覆盖所有场景。第三验证要跑完整流程。改完配置后别只看当前窗口要重启终端、多开几个会话、甚至升级后再测一遍。我见过太多当时好了过两天又弹的情况都是因为验证不充分。第四保留一份可回滚的配置备份。配置改坏了会导致 Claude Code 行为异常有备份能快速恢复。备份不用很复杂复制一份加个日期就行。第五关注版本更新对配置的影响。Claude Code 迭代快配置项会变。升级后花两分钟扫一眼日志能避免很多配置突然失效的困惑。这套方法不只适用于关闭这条 classifier 通知Claude Code 其他类似的通知和提示处理思路都是相通的找到控制它的配置项确认生效路径设置并验证。掌握这个套路以后遇到新的提示弹窗你自己就能快速定位和解决不用每次都去搜教程。
Claude Code auto mode classifier 免费通知反复弹出？配置层彻底关闭指南
1. 那条反复弹出的提示到底在说什么如果你最近在终端里跑 Claude Code大概率见过这么一条提示were changing auto mode to no longer charge for classifier requests。它会在你每次启动会话、或者隔一段时间就冒出来一次像极了那种关不掉的系统更新弹窗。很多人第一反应是我是不是哪里配置错了然后开始翻文档、查环境变量折腾半天发现根本没用——因为这条提示本身不是错误而是产品侧的一个变更通知。先把事情说清楚。Claude Code 的 auto mode 里有一个叫 classifier 的组件它的作用是判断当前这个请求该走哪条路径、要不要触发自动决策逻辑。早期这个 classifier 的调用是计入用量成本的后来官方调整策略classifier requests 不再单独计费。为了告知用户这个变化客户端会在会话里推送这条通知。问题在于这个通知的触发逻辑比较激进导致它在很多场景下反复出现干扰了正常的命令行工作流。这条提示的核心关键词有三个auto mode、classifier requests、免费。auto mode 是 Claude Code 的一种运行模式开启后它会自动判断任务类型并选择合适的处理方式不需要你每次手动指定。classifier requests 指的是 auto mode 内部用来做请求分类的那些调用。免费则是指这部分调用不再产生额外费用。三者串起来就是auto mode 下的分类请求现在不收费了客户端在通知你这个事。那为什么它会反复出现这就要说到客户端的通知机制了。根据实际观察这条提示的展示逻辑和会话状态、配置读取、以及本地缓存都有关系。如果你的配置文件里没有明确记录已读状态或者环境变量没有正确传递客户端每次启动都会认为你是第一次看到这个通知于是再弹一遍。这不是 bug而是通知去重机制在特定配置下失效的表现。适合读这篇内容的人很明确已经在用 Claude Code、被这条提示烦到、想彻底关掉它的人。如果你还没装 Claude Code这篇也能帮你提前理解它的配置体系避免以后踩同样的坑。下面我会从提示的触发原理讲起然后给出几种不同层级的关闭方案最后说说我在实操中遇到的几个意外情况。2. 通知反复触发的三个真实原因2.1 配置状态没有持久化到本地Claude Code 的很多行为依赖本地配置文件最典型的就是settings.json。这个文件通常位于用户目录下的配置文件夹里记录着你的偏好设置、已读通知、功能开关等信息。当客户端推送那条 classifier 通知时它会在本地写一个标记表示这个通知用户已经看过了。下次启动时先读这个标记有标记就不再弹。问题出在写入环节。如果你的settings.json所在目录权限不对或者文件被其他进程占用写入就会失败。写入失败但客户端不报错只是默默地在下次启动时重新弹通知。我遇到过一种情况配置文件被同步工具锁定了每次写入都被拦截导致通知连续弹了十几次。排查的时候可以看一下配置文件的修改时间如果它一直不更新基本就是写入被阻断了。还有一种更隐蔽的情况你用了多个终端会话或者在不同的工作目录下启动 Claude Code。如果客户端把状态写在了项目级的配置里而不是用户级的配置里那么换个目录启动就会重新弹。这种设计在多人协作场景下有一定道理但对个人用户来说就是纯粹的干扰。2.2 环境变量没有正确传递CLAUDE_CODE_AUTO_MODE_SERVER这个环境变量是控制 auto mode 服务端行为的关键开关。它的值决定了客户端在启动时如何初始化 auto mode 相关的逻辑包括是否检查通知状态、是否走服务端下发的配置。如果你在 shell 里临时 export 了这个变量但没有写进 shell 的启动脚本比如.bashrc、.zshrc或 Windows 的环境变量设置那么新开的终端会话就读不到它。读不到的时候客户端会走默认逻辑而默认逻辑里通知检查是开启的。这就解释了为什么有些人明明设置过了但重启终端后提示又回来了。环境变量的作用域是个容易被忽略的点。在 Linux 和 macOS 上你在当前终端 export 的变量只对当前会话和它的子进程有效。关掉终端就没了。在 Windows 上通过命令行 set 设置的变量也是临时的只有通过系统属性面板或者 setx 命令设置的才是持久的。很多人卡在这一步以为设置完了其实只是当前窗口有效。2.3 客户端版本与通知逻辑的错配Claude Code 更新比较频繁不同版本对通知的处理逻辑有差异。有些版本里通知的去重依赖服务端返回的一个状态字段有些版本里这个逻辑改成了纯本地判断。如果你用的版本正好处于逻辑切换的过渡期就可能出现本地以为该弹、服务端以为不该弹的错配。这种情况的典型表现是你按照旧版本的教程改了配置但新版本已经不读那个配置项了于是提示照弹不误。反过来也一样新版本的配置项在旧版本里不存在改了也没用。判断方法很简单跑一下claude --version看当前版本号然后对照官方更新日志里关于 auto mode 和 classifier 的条目。如果日志里提到通知逻辑有变更那基本就是版本错配的问题。提示不要盲目照搬网上搜到的配置片段。Claude Code 的配置项在不同版本间有增删先确认版本再动手能省掉大量无效折腾。这三个原因经常是叠加出现的。比如你环境变量没设对同时配置文件又没写权限那通知就会以各种你意想不到的方式反复出现。排查的时候建议按先看配置文件、再看环境变量、最后看版本的顺序来从最容易被忽略的地方入手。3. 从配置层彻底关掉这条提示3.1 修改 settings.json 的正确姿势最直接的办法是在settings.json里显式关闭这个通知。这个文件的位置因系统而异Linux 和 macOS 通常在~/.config/claude-code/settings.json或者~/.claude/settings.jsonWindows 在%APPDATA%\claude-code\settings.json。如果你不确定具体路径可以在 Claude Code 里执行一个查看配置的命令或者直接搜一下用户目录下叫 settings.json 的文件。打开文件后你需要关注的是和 auto mode、notification 相关的字段。根据实际配置经验通常需要设置类似这样的结构{ autoMode: { classifierNotification: false, showUpgradePrompts: false }, notifications: { dismissed: [auto_mode_classifier_free] } }这里解释一下每个字段的意图。classifierNotification控制是否展示 classifier 相关的通知设为 false 就是直接关掉。showUpgradePrompts控制升级提示因为这条通知有时候和版本升级提示是绑在一起推的一起关掉更干净。dismissed数组里记录已经关闭过的通知 ID把 classifier 那条的 ID 加进去客户端下次检查时就会跳过。改完之后有个关键动作确认文件真的被保存了。我见过有人用编辑器改完没保存就重启然后说配置没用。另外如果文件里已经有其他配置注意 JSON 的语法多一个逗号少一个引号都会导致整个文件解析失败客户端会回退到默认配置通知照弹。改完可以用python -m json.tool settings.json验证一下语法。3.2 环境变量的持久化设置CLAUDE_CODE_AUTO_MODE_SERVER这个变量的设置方式取决于你的操作系统和 shell。它的作用是指定 auto mode 服务端的地址或行为模式间接影响通知的拉取逻辑。把它设成一个明确的值可以避免客户端走默认的检查流程。在 Linux 和 macOS 上如果你用的是 bash编辑~/.bashrc用 zsh 就编辑~/.zshrc。在文件末尾加上export CLAUDE_CODE_AUTO_MODE_SERVERlocal然后执行source ~/.bashrc或source ~/.zshrc让配置立即生效。验证方法是新开一个终端跑echo $CLAUDE_CODE_AUTO_MODE_SERVER能打印出 local 就说明设置成功了。Windows 用户分两种情况。如果你用 PowerShell可以执行[Environment]::SetEnvironmentVariable(CLAUDE_CODE_AUTO_MODE_SERVER, local, User)这条命令会把变量写到用户级环境变量里重启终端后生效。如果你用 CMD用setx CLAUDE_CODE_AUTO_MODE_SERVER local效果一样。注意 setx 设置完后当前窗口不会立即生效需要新开一个窗口。注意环境变量的值不要随便填。local表示走本地逻辑不依赖服务端下发配置这是关闭通知最稳妥的方式。填其他值可能触发不同的行为分支反而让问题更复杂。3.3 配置文件与环境变量的优先级关系这里有个很多人搞混的点配置文件和环境变量同时存在时谁说了算根据实际测试Claude Code 的读取顺序是环境变量优先于配置文件。也就是说如果你在 settings.json 里关了通知但环境变量里有个值强制开启了服务端检查那通知还是会弹。这个优先级设计有它的道理环境变量适合做临时覆盖和不同环境下的差异化配置配置文件适合做长期偏好。但对我们来说意味着两处都要设置正确不能只改一处。我建议的做法是配置文件里做完整的关闭设置环境变量里设一个明确的值来固化行为两者配合基本可以杜绝反复弹窗。如果你在团队环境里用 Claude Code还要注意项目级配置和用户级配置的覆盖关系。项目级的 settings.json 如果存在会覆盖用户级的部分设置。检查一下你的项目根目录下有没有.claude/settings.json之类的文件有的话也要同步修改。4. 不同系统下的实操差异与验证4.1 Linux 和 macOS 的完整操作链路在 Linux 和 macOS 上整个操作可以串成一条清晰的链路。先定位配置文件用ls -la ~/.config/claude-code/或ls -la ~/.claude/看看文件在不在、权限对不对。权限建议是 644也就是你自己可读写其他人只读。如果权限是 600 或者更严格一般也没问题但如果是 root 拥有的文件而你用普通用户跑 Claude Code写入就会失败。然后编辑配置文件加上前面说的那些字段。保存后用cat或者jq确认内容正确。接着设置环境变量写进 shell 启动脚本。最后新开一个终端跑一次 Claude Code观察通知是否还出现。验证的时候有个小技巧先故意不改配置启动一次记下通知出现的时间点。然后改完配置再启动对比两次的行为。如果第二次启动后通知没出现而且持续用了几分钟也没弹基本就成功了。如果还弹检查一下是不是有多个配置文件、或者环境变量没生效。macOS 上还有个特殊情况如果你用 Homebrew 装的 Node环境变量的加载路径可能和系统自带的不一样。确认一下你的 shell 启动脚本是不是被正确加载了可以在脚本里加一行echo shell config loaded启动终端时看看有没有输出。4.2 Windows 下的路径与权限坑Windows 的配置路径和权限模型跟 Unix 系差别很大坑也更多。配置文件通常在%APPDATA%\claude-code\settings.json这个路径可以用echo %APPDATA%在 CMD 里查看或者在 PowerShell 里用$env:APPDATA。权限方面Windows 的用户目录一般不会有写入问题但如果你把 Claude Code 装在系统级目录下或者用管理员权限装过什么东西可能导致配置文件的所有者变成管理员账户普通用户写入被拒。检查方法是右键文件看属性里的安全选项卡确认你的用户账户有写入权限。环境变量在 Windows 上要特别注意用户变量和系统变量的区别。用户变量只对当前用户生效系统变量对所有用户生效。个人使用设用户变量就够了设系统变量反而可能影响其他账户。设置完之后一定要新开一个 CMD 或 PowerShell 窗口验证老窗口读的是旧的环境变量快照。还有一个 Windows 特有的问题如果你同时装了 WSL 和 Windows 原生版 Claude Code两者的配置是独立的。在 WSL 里改的配置不会影响 Windows 原生版反之亦然。搞清楚你平时用的是哪个别改错了地方。4.3 验证关闭效果的三种方法改完配置不能只看这次没弹要确认是持久生效的。我常用三种验证方法组合起来基本能覆盖所有情况。第一种是重启验证。完全关掉所有终端窗口重新打开启动 Claude Code观察前几分钟有没有通知。这是最基础的验证能排除临时状态的影响。第二种是多会话验证。同时开两三个终端分别在不同目录下启动 Claude Code。如果通知只在某个目录下出现说明是项目级配置的问题如果都不出现说明用户级配置生效了。第三种是版本升级后验证。Claude Code 升级后配置项有可能被重置或者新增检查逻辑。升级完先跑一次看通知有没有回来。如果回来了对照更新日志看看是不是新增了配置项补上就行。验证方法操作要点能发现的问题重启验证关闭所有终端后重新启动临时状态干扰、环境变量未持久化多会话验证不同目录同时启动多个实例项目级配置覆盖、路径相关问题升级后验证版本更新后立即测试配置项失效、新增检查逻辑这三种方法我一般会在改完配置后一次性跑完虽然多花几分钟但能避免以为关掉了结果过两天又弹的尴尬。5. 那些文档里不会写的踩坑记录5.1 配置文件被同步工具锁定的排查过程前面提到过配置文件写入失败的情况这里展开说一个我实际遇到的案例。当时我在一台开发机上改完 settings.json重启 Claude Code通知还在。反复检查配置内容语法没问题路径也对。后来用stat命令看文件的修改时间发现它停留在几天前也就是说我的修改根本没写进去。进一步排查发现这台机器上装了一个文件同步工具它会监控配置目录任何写入都会被它拦截并尝试同步到远端。同步过程中文件被锁定Claude Code 的写入操作就失败了。解决办法是把配置目录加入同步工具的排除列表或者临时暂停同步再改配置。这个坑的隐蔽之处在于编辑器里看文件内容是对的因为编辑器读的是缓存或者同步下来的版本但实际磁盘上的文件没变。判断方法是改完配置后用命令行cat一下看内容是不是真的更新了。如果编辑器显示的和命令行显示的不一致基本就是同步工具在捣鬼。5.2 多版本共存导致的配置混乱有些人机器上同时装了多个版本的 Claude Code比如一个通过 npm 全局装的一个通过其他包管理器装的还有一个是手动下载的。这些版本可能读不同的配置文件或者读同一个文件但解析逻辑不同。我遇到过的情况是npm 版读~/.claude/settings.json手动安装版读~/.config/claude-code/settings.json。我只改了其中一个结果用另一个版本启动时通知照弹。排查的时候用which claude看当前用的是哪个可执行文件然后顺着它的安装路径找配置文件。多版本共存的另一个问题是环境变量。不同版本可能对同一个环境变量有不同的解释。比如CLAUDE_CODE_AUTO_MODE_SERVER在旧版本里可能只接受特定几个值新版本里接受任意字符串。如果你在旧版本里设了一个新版本才支持的值旧版本可能直接忽略走默认逻辑。提示如果你不确定自己装了几个版本用which -a claudeLinux/macOS或where claudeWindows列出所有可执行文件路径逐个确认。5.3 通知关闭后功能受影响的边界关掉通知本身是安全的但要注意别把相关的功能开关一起关了。有些配置项是通知和功能绑定的关通知的同时会把功能也禁用。比如 auto mode 的某些自动决策逻辑如果它的开关和通知开关是同一个字段关了之后 auto mode 可能就不自动了变成每次都要手动指定。判断方法是关掉通知后实际跑几个任务看 auto mode 的行为有没有变化。如果发现它不再自动选择处理路径了说明关过头了需要把功能开关单独打开。理想的做法是找到只控制通知展示的那个字段而不是控制整个 auto mode 的字段。从我的经验看classifierNotification这类字段通常只影响展示层不会动到核心逻辑。但autoMode下的一些其他字段就不好说了改之前最好备份一下配置文件出问题能快速回滚。6. 让配置长期稳定的几个习惯6.1 把配置纳入版本管理配置文件改来改去时间长了容易忘记改过什么。我的做法是把settings.json纳入个人 dotfiles 仓库用 git 管理。每次修改都提交一次写清楚改了什么、为什么改。这样出问题的时候可以快速对比历史版本也能在新机器上快速恢复配置。具体操作是在 dotfiles 仓库里建一个 claude-code 目录把配置文件软链接过去或者写一个安装脚本在部署时复制过去。软链接的好处是改一处两边同步坏处是某些系统对软链接的支持不一致。复制的方式更稳妥但需要记得改完源文件后重新部署。环境变量的设置也可以写进 dotfiles 的 shell 配置里和配置文件一起管理。这样换机器的时候clone 仓库、跑一下安装脚本环境和配置就都齐了。6.2 升级前先备份配置Claude Code 升级有可能重置或迁移配置。虽然大多数时候升级是平滑的但涉及配置结构变更的版本升级过程可能会覆盖你的自定义设置。养成升级前备份的习惯能省掉很多麻烦。备份很简单把配置文件和 shell 配置里相关的行复制一份加上日期后缀。升级完对比一下看有没有被改动。如果被改了把备份里的自定义部分合并回去。这个操作花不了一分钟但能在出问题时救急。6.3 关注官方更新日志里的配置变更Claude Code 的更新日志里会提到配置项的增删改。养成升级后扫一眼日志的习惯重点看和 auto mode、notification、环境变量相关的条目。如果日志里说某个配置项废弃了或者新增了及时调整自己的配置避免用着废弃的字段还以为生效了。日志里如果提到通知逻辑优化之类的描述更要留意因为这往往意味着通知的触发条件变了原来的关闭方法可能失效。这时候需要重新测试找到新的关闭方式。7. 关于这条提示的几个常见误解7.1 这不是错误是产品变更通知很多人看到提示反复出现第一反应是是不是我哪里配错了。其实这条提示本身是正常的产品变更通知不是错误信息。它的目的是告知用户 classifier requests 不再收费属于信息传达不是故障报警。理解这一点很重要能避免你在错误的方向上排查。当然通知反复出现确实是个体验问题但它的根源是通知去重机制在特定配置下失效而不是你的环境坏了。所以解决思路应该是调整配置让去重生效而不是修复某个损坏的东西。7.2 关闭通知不影响正常使用有人担心关掉通知会不会影响 auto mode 的功能或者导致某些请求走错路径。从实际使用来看关闭通知只影响展示层不影响 classifier 的实际工作。classifier 该跑还是跑该分类还是分类只是不再弹那条提示了。如果你实在不放心可以在关闭通知后跑几个不同类型的任务观察 auto mode 的选择结果和之前有没有差异。我测试下来是没有差异的auto mode 的行为完全一致。7.3 免费不等于无限制提示里说的免费是指 classifier requests 不再单独计费但不代表整个 Claude Code 的使用完全免费。其他类型的请求、超出配额的部分该计费还是计费。别看到免费两个字就以为可以随便用具体还是要看你的订阅方案和用量情况。这个区分很重要因为有些人可能会误解提示的含义以为所有请求都免费了。实际上只是 classifier 这一块的计费策略调整其他部分不变。8. 我在实际配置中总结的几条经验折腾这条提示的过程中我积累了几个比较实用的经验分享出来供参考。第一改配置前先确认当前生效的配置文件路径。不同安装方式、不同版本读的文件可能不一样盲目改一个可能根本没被读取。用claude --version和which claude确认版本和路径再顺着找配置文件比到处乱改高效得多。第二环境变量和配置文件要一起改。只改一个往往不够因为两者的优先级和生效范围不同。环境变量管当前会话和子进程配置文件管长期偏好配合使用才能覆盖所有场景。第三验证要跑完整流程。改完配置后别只看当前窗口要重启终端、多开几个会话、甚至升级后再测一遍。我见过太多当时好了过两天又弹的情况都是因为验证不充分。第四保留一份可回滚的配置备份。配置改坏了会导致 Claude Code 行为异常有备份能快速恢复。备份不用很复杂复制一份加个日期就行。第五关注版本更新对配置的影响。Claude Code 迭代快配置项会变。升级后花两分钟扫一眼日志能避免很多配置突然失效的困惑。这套方法不只适用于关闭这条 classifier 通知Claude Code 其他类似的通知和提示处理思路都是相通的找到控制它的配置项确认生效路径设置并验证。掌握这个套路以后遇到新的提示弹窗你自己就能快速定位和解决不用每次都去搜教程。