ollama v0.40.3 发布：Claude 连接器提示消失、Codex 服务等级告警取消、本地模型兼容迁移暂停

2026年10月11日，Ollama 发布 v0.40.3 版本。本次版本规模不大，但更新非常集中，围绕ollama launch claude、ollama launch codex以及本地模型兼容性迁移三个方向进行了调整。

从变更数据来看，v0.40.3 共包含 3 次提交，涉及 6 个文件，整体代码变更为 61 行新增、11 行删除。虽然没有新增大量功能，但每一项调整都直接面向实际使用中的提示、告警和请求性能问题。

本次更新可以概括为三件事：

•ollama launch claude不再显示 Claude 连接器相关警告

•ollama launch codex不再显示服务等级相关警告

• 暂停嵌入模型及其他请求性能相关的后台模型升级与本地兼容性迁移

下面结合具体代码改动，详细拆解 Ollama v0.40.3 的更新内容。

一、v0.40.3 更新概览

本次版本的发布时间为 2026 年 10 月 11 日，主要包含以下三项变更。

变更方向

核心调整

Claude 启动

关闭 ClaudeAI MCP Servers，消除连接器相关警告

Codex 启动

默认指定service_tier="default"，避免继承服务等级设置导致告警

服务端模型调度

暂停本地模型兼容性迁移，避免后台升级影响 embedding 和其他请求性能

对应的提交时间分布如下：

• 2026 年 10 月 9 日：调整 Codex 的服务等级配置

• 2026 年 10 月 9 日：调整 Claude Code 连接器提示行为

• 2026 年 10 月 10 日：暂停本地模型兼容性迁移

这意味着 v0.40.3 的主要目标不是增加新模型能力，而是让现有的启动命令更安静、更稳定，并降低后台迁移行为对请求性能的影响。

二、Claude 启动行为调整：禁用 ClaudeAI MCP Servers

本次更新修改了cmd/launch/claude.go。

在 Claude 的环境变量配置中，Ollama 新增了一项环境变量：

ENABLE_CLAUDEAI_MCP_SERVERS=false

Claude 启动时原本已经会设置一批 Ollama 管理的环境变量，包括：

ANTHROPIC_BASE_URL= 

ANTHROPIC_API_KEY=
ANTHROPIC_AUTH_TOKEN=ollama
CLAUDE_CODE_ATTRIBUTION_HEADER=0
CLAUDE_CODE_TOTAL_TOKENS_REMINDER=off
DISABLE_ERROR_REPORTING=1

在 v0.40.3 中，这组配置中新增了：

ENABLE_CLAUDEAI_MCP_SERVERS=false

这项设置的直接作用是：当通过ollama launch claude启动 Claude 时，明确关闭 ClaudeAI MCP Servers，从而不再显示 Claude 连接器相关的警告信息。

换句话说，Ollama 不再让 Claude 的连接器配置继承外部环境中的相关状态，而是在启动子进程时主动指定：

ENABLE_CLAUDEAI_MCP_SERVERS=false

这样可以避免用户本机环境变量、已有配置或其他启动上下文对 Ollama 启动的 Claude 造成干扰。

三、Claude 环境变量测试同步增强

为了验证这项行为，v0.40.3 同时修改了cmd/launch/claude_test.go。

首先，原有的 Claude 环境变量测试新增了对应断言，确认最终生成的环境变量中包含：

ENABLE_CLAUDEAI_MCP_SERVERS=false

测试中的预期环境变量映射现在包含以下关键内容：

ANTHROPIC_BASE_URL
ANTHROPIC_API_KEY
ANTHROPIC_AUTH_TOKEN
ENABLE_CLAUDEAI_MCP_SERVERS
CLAUDE_CODE_ATTRIBUTION_HEADER
CLAUDE_CODE_TOTAL_TOKENS_REMINDER
DISABLE_ERROR_REPORTING

其中：

ANTHROPIC_BASE_URL

会被设置为 Ollama 当前服务地址。

ANTHROPIC_API_KEY

被设置为空值。

ANTHROPIC_AUTH_TOKEN

被设置为：

ollama

而新增的：

ENABLE_CLAUDEAI_MCP_SERVERS

则必须为：

false

这表明该配置不是一个可选的默认行为，而是 Ollama 在调用 Claude 时明确管理的一部分启动环境。

四、新增 Claude 运行测试：不会继承父进程连接器配置

v0.40.3 还新增了一个专门的测试，用于验证 Claude 启动时不会继承父进程中已经存在的 ClaudeAI MCP Servers 配置。

测试名称表达的核心目的非常清晰：运行 Claude 时禁用 ClaudeAI Connectors。

测试覆盖了两种模型：

llama3.2
kimi-k3:cloud

这两种模型分别代表不同的模型启动场景，但最终都需要满足相同的环境隔离要求。

测试开始时，先在父进程环境中设置以下变量：

ENABLE_CLAUDEAI_MCP_SERVERS=true
OLLAMA_HOST=http://127.0.0.1:12345
ANTHROPIC_API_KEY=test-api-key
ANTHROPIC_AUTH_TOKEN=test-auth-token

其中最关键的是：

ENABLE_CLAUDEAI_MCP_SERVERS=true

这代表父进程显式开启了相关能力。

然后，测试通过临时目录、临时可执行文件和环境输出方式，检查最终启动的 Claude 子进程实际接收到的环境变量和参数。

验证结果要求 Claude 子进程中必须看到：

ENABLE_CLAUDEAI_MCP_SERVERS=false

而不是父进程中设置的：

true

这证明ollama launch claude会覆盖父进程已有的该环境变量。

同时，测试还验证了以下内容。

Claude 子进程中的 Ollama 服务地址必须为：

http://127.0.0.1:12345

Claude 子进程中的 API Key 必须为空：

ANTHROPIC_API_KEY=

Claude 子进程中的认证 Token 必须为：

ANTHROPIC_AUTH_TOKEN=ollama

即使父进程中原本存在：

ANTHROPIC_API_KEY=test-api-key
ANTHROPIC_AUTH_TOKEN=test-auth-token

Claude 子进程也不会继续使用它们。

此外，测试还验证了 Claude 接收到的命令行参数是否保持正确。调用时传入：

--mcp-config 
<临时配置文件路径>

最终 Claude 子进程收到的参数顺序应包括：

--model
 
<模型名称>
--mcp-config
 
<临时配置文件路径>

这意味着，本次关闭 ClaudeAI MCP Servers 的改动不会破坏用户通过命令行传入的 MCP 配置参数。

值得注意的是，测试最后还会重新检查父进程中的环境变量：

ENABLE_CLAUDEAI_MCP_SERVERS=true

必须仍然保持为true。

这一点非常重要。它说明 Ollama 的处理方式是只为 Claude 子进程设置独立环境，而不是修改当前终端、当前进程或系统级的环境变量。

也就是说，v0.40.3 的行为可以概括为：

• 父进程已有的连接器设置不会直接传入 Claude

• Claude 子进程被强制设置为false

• 父进程自身的环境变量不会被修改

• 传入的模型参数和 MCP 配置参数仍然保留

对于通过ollama launch claude使用本地模型或云端模型的用户来说，这项更新减少了不必要的连接器警告，同时保持了命令行启动方式的稳定性。

五、Codex 启动行为调整：默认指定服务等级

第二项重要改动位于cmd/launch/codex.go。

v0.40.3 为 Codex 启动参数新增了一项配置：

-c service_tier="default"

从代码逻辑来看，Codex 启动时原本会先写入 Ollama 管理的配置覆盖项，包括模型提供方、基础地址、接口类型以及模型目录路径等内容。

在 v0.40.3 中，Ollama 会在这些受管理配置之后，额外添加：

-c service_tier="default"

随后才根据模型是否为空，决定是否继续追加：

-m 
<模型名称>

因此，当执行类似命令时：

ollama launch codex llama3.2

Codex 获得的启动配置中将包含：

service_tier="default"

这项调整的目的，是避免 Codex 继承已有配置中的服务等级，从而不再出现服务等级相关警告。

六、为什么要显式设置 service_tier=”default”

此次更新描述中明确指出，ollama launch codex不再对服务等级显示警告。

从测试内容可以看到，Codex 的用户配置中可能存在类似配置：

service_tier = "priority"

例如，测试使用的用户根配置中包含：

model = "gpt-5.5"
model_reasoning_effort = "max"
service_tier = "priority"
model_provider = "openai"

同时还包含对应的模型提供方配置：

[model_providers.openai]
name = "OpenAI"

在这种情况下，如果 Ollama 启动 Codex 时不主动管理service_tier，那么用户原有的：

service_tier = "priority"

就可能继续生效，进而触发服务等级相关提示或警告。

v0.40.3 通过在启动命令中加入：

-c service_tier="default"

使 Ollama 启动的 Codex 默认使用：

default

而不是继承已有根配置中的服务等级。

这正是更新说明中“避免继承服务等级警告”的核心。

七、Codex 参数测试更新：默认值与显式覆盖并存

在cmd/launch/codex_test.go中，v0.40.3 同步更新了参数测试。

测试中的受管理参数新增：

-c service_tier="default"

因此，Codex 启动时的基础参数中，现在至少会包括以下类别：

模型提供方名称
模型提供方基础地址
模型提供方接口类型
模型目录路径
默认服务等级

对应到参数形式，关键新增内容为：

-c
service_tier="default"

测试覆盖了多种情况。

第一种是指定模型启动：

llama3.2

此时会在受管理配置后追加：

-m
llama3.2

第二种是模型名称为空。

此时不会追加模型参数，但仍然会保留：

-c service_tier="default"

第三种是附加沙盒参数，例如：

--sandbox workspace-write

在这种情况下，默认服务等级仍然存在，并且用户附加的沙盒参数会继续传递。

第四种是用户显式传入服务等级，例如：

-c service_tier="priority"

测试期望的最终参数同时包含：

-c service_tier="default"

以及用户额外传入的：

-c service_tier="priority"

这意味着 v0.40.3 并没有删除用户通过命令行显式提供的服务等级配置，而是在 Ollama 管理的启动参数中先加入默认等级，再保留额外参数。

因此，本次变更的重点不是移除服务等级设置，而是确保ollama launch codex有一个明确的默认服务等级：

default

同时，用户提供的附加命令行参数仍然会被保留。

八、Codex 配置恢复测试：不改写用户根配置

Codex 相关测试中还更新了一处用户根配置样例，新增了：

service_tier = "priority"

这部分测试的主题是：恢复操作移除 CLI Profile 和 Catalog 时，不改变用户根配置。

测试配置中保留了用户已有的内容，包括：

model = "gpt-5.5"
model_reasoning_effort = "max"
service_tier = "priority"
model_provider = "openai"

这反映出一个明确的边界：

• Ollama 在启动 Codex 时可以通过命令行参数加入受管理配置

• Ollama 可以控制启动时的默认服务等级

• 但恢复 CLI Profile 和 Catalog 的流程不应修改用户原有的根配置内容

也就是说，用户配置文件中已有的：

service_tier = "priority"

仍然属于用户配置的一部分，不会因为 Ollama 启动时追加了：

service_tier="default"

而被直接删除或改写。

对于已经存在 Codex 配置、并且拥有自定义模型、推理强度、服务等级和模型提供方设置的用户来说，这项测试保证了启动流程与配置恢复流程之间的边界更加明确。

九、暂停本地模型兼容性迁移

本次版本第三项更新来自服务端模型调度逻辑，涉及文件：

server/routes.go

此前，在服务端为模型调度运行器时，Ollama 会检查模型名称与运行器类型。

原有逻辑大致包含以下判断：

• 解析模型名称

• 判断模型名称是否为摘要引用

• 获取模型的 Runner

• 如果 Runner 为空且模型属于 GGUF，则使用 GGML Runner

• 如果最终 Runner 为 GGML，则启动本地兼容性迁移

其中最关键的原有调用是：

compatmigrate.StartLocalCompatibilityMigration(selectedName)

该调用意味着：当满足对应条件时，Ollama 会启动本地模型兼容性迁移。

在 v0.40.3 中，这段逻辑被整体注释，并新增了一条明确标注：

TODO: enable compatibility migration

也就是说，本地兼容性迁移在当前版本被暂停。

十、本地兼容性迁移暂停的触发范围

根据原有逻辑，本地兼容性迁移针对的不是所有模型，而是满足以下条件的模型。

首先，模型名称不能是摘要引用名称。

其次，需要确定模型的 Runner。

如果模型本身未指定 Runner，且模型属于 GGUF 格式，则会使用：

GGML

作为运行器。

当最终 Runner 为：

GGML

时，原本会调用本地兼容性迁移逻辑。

可以将原来的判断链路理解为：

模型不是摘要引用
→ 获取 Runner
→ Runner 为空且模型为 GGUF
→ 使用 GGML Runner
→ Runner 为 GGML
→ 启动本地兼容性迁移

而 v0.40.3 中，这整段调用路径已被注释，当前不会执行本地兼容性迁移。

代码中保留了原逻辑，但明确通过注释标记为后续待重新启用的能力。

十一、为什么暂停兼容性迁移

版本说明中明确提到，本次更新暂停了与 embedding 及其他请求性能相关的后台模型升级。

对应到服务端代码，暂停的正是：

StartLocalCompatibilityMigration

也就是本地兼容性迁移的启动过程。

从更新方向可以看到，Ollama v0.40.3 的策略是暂时不在模型请求相关流程中启动这类后台迁移行为，以减少其对 embedding 和其他请求性能的影响。

这项调整不代表相关兼容性迁移逻辑被删除。

相反，代码仍然保留了完整的原判断逻辑，只是被注释起来，并写明：

TODO: enable compatibility migration

因此，v0.40.3 的状态是：

• 本地兼容性迁移逻辑仍然存在

• 当前版本不执行该逻辑

• 后续可能重新启用

• 当前优先级是避免后台迁移影响请求性能

十二、兼容性迁移测试同步暂停

为了与服务端逻辑保持一致，v0.40.3 还修改了：

integration/migration_test.go

在本地兼容性迁移测试的开头，新增了跳过测试的语句，表达的含义是：

local compatibility migration is paused

也就是说：

TestLocalCompatibilityMigration

在当前版本会直接跳过。

原本该测试中还会继续判断是否存在：

OLLAMA_TEST_EXISTING

如果该环境变量不为空，测试会因为需要由测试工具管理的服务端而跳过。

但在 v0.40.3 中，由于本地兼容性迁移本身已经暂停，因此测试会更早被直接跳过。

这与server/routes.go中的处理完全一致：

• 服务端不再启动本地兼容性迁移

• 集成测试不再执行本地兼容性迁移验证

• 代码保留未来重新启用的入口

十三、与视觉模型兼容性提示无关的部分保持不变

在暂停本地兼容性迁移的代码位置之后，服务端仍保留了对特定视觉模型兼容性的检查。

当模型家族包含：

mllama

并且存在投影器路径时，服务端仍会返回对应的兼容性错误提示。

提示的核心内容是：

llama3.2-vision 不再兼容当前版本的 Ollama，需要重新下载

并给出重新下载命令：

ollama pull llama3.2-vision

这部分逻辑在 v0.40.3 中没有被移除。

因此，需要区分两类行为：

• 本地 GGML 模型的兼容性迁移：当前暂停

• 特定视觉模型不兼容时的错误提示与重新下载建议：仍然保留

本次更新暂停的是后台兼容性迁移调用，并不是删除所有模型兼容性检查。

十四、v0.40.3 对实际使用的影响

从用户角度看，Ollama v0.40.3 最直观的变化主要体现在启动体验和请求流程两方面。

对于 Claude 用户：

•ollama launch claude会主动关闭 ClaudeAI MCP Servers

• 连接器相关警告不再出现

• 父进程中已有的连接器环境变量不会被直接继承

• 父进程中的环境变量本身不会被修改

•--mcp-config等命令行参数仍然可以正常传递

• Ollama 管理的认证地址、认证 Token 和 API Key 设置仍然生效

对于 Codex 用户：

•ollama launch codex会自动附加service_tier="default"

• 不再因继承已有服务等级配置而出现相关警告

• 用户原有根配置不会被恢复流程改写

• 用户通过命令行额外传入的服务等级参数仍会被保留

• 模型、沙盒参数和其他额外参数的传递逻辑保持不变

对于本地模型和 embedding 请求场景：

• 当前版本不再启动本地兼容性迁移

• 与兼容性迁移相关的集成测试同步暂停

• 后台模型升级和迁移行为不再影响当前请求流程

• 相关逻辑没有删除，而是等待后续重新启用

十五、总结：v0.40.3 是一次面向稳定性的精细更新

代码地址：github.com/ollama/ollama

Ollama v0.40.3 虽然只包含 3 次提交，但三个改动都非常明确。

第一，Claude 启动流程中新增：

ENABLE_CLAUDEAI_MCP_SERVERS=false

从而关闭 ClaudeAI MCP Servers，避免 Claude 连接器相关警告，并通过测试确认不会继承父进程中已有的连接器、API Key 和认证 Token 配置。

第二，Codex 启动流程中新增：

-c service_tier="default"

从而避免继承已有服务等级配置导致的告警。与此同时，用户原有的根配置不会被改写，命令行显式传入的服务等级参数也仍会保留。

第三，服务端暂停本地兼容性迁移调用，并同步跳过对应的集成测试。当前代码通过待办标记保留重新启用入口，短期内则优先避免后台迁移对 embedding 和其他请求性能造成影响。

整体来看，Ollama v0.40.3 的关键词是：

减少警告
隔离启动环境
明确默认配置
暂停后台迁移
保障请求性能

如果你正在使用ollama launch claude或ollama launch codex，这一版本会让启动过程更加可控；如果你在本地模型、embedding 或其他请求中关注性能波动，v0.40.3 对本地兼容性迁移的暂停也值得重点关注。

我们相信人工智能为普通人提供了一种“增强工具”，并致力于分享全方位的AI知识。在这里，您可以找到最新的AI科普文章、工具评测、提升效率的秘籍以及行业洞察。 欢迎关注“福大大架构师每日一题”，发消息可获得面试资料，让AI助力您的未来发展。