Cursor接入Ollama报“user is unauthorized”或“401 Unauthorized”，主因是Ollama原生API无需认证，但Cursor强制注入了无效Authorization头；应将Cursor中Ollama模型的API Key字段留空或填none，并确认Ollama未被反向代理加Auth，必要时重生成密钥对并登录。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Cursor接入Ollama时提示“user is unauthorized”或“401 Unauthorized”，说明请求被Ollama服务端拒绝认证，不是网络不通或模型不存在的问题，而是身份凭证缺失、过期或不匹配导致的明确权限拦截。
确认Ollama是否启用认证机制
默认情况下，本地运行的Ollama服务（ollama serve）不强制认证——它只在调用远程仓库（如push/pull私有模型）或访问受控API端点时才触发鉴权。但如果你启用了Ollama的Enterprise版、自建代理层，或通过Nginx反向代理加了Basic Auth，就可能误将本地API请求也纳入认证范围。
执行curl -v http://localhost:11434/api/tags。若返回401 Unauthorized且响应头含WWW-Authenticate字段，说明服务端主动要求认证；若返回200 JSON，则问题不在Ollama本身，而是Cursor配置中混入了不该有的认证头。
检查Cursor配置中是否错误添加了API Key
Ollama原生API无需Bearer Token或API Key——它的本地调用是无状态、无密钥的。但Cursor的Model Provider设置页里，“API Key”字段为必填项，很多人会随手填入ollama、dummy甚至OpenRouter的密钥，这会导致请求头带上Authorization: Bearer ollama，而Ollama服务端不认识该Token，直接拒收。
打开Cursor设置 → AI → Model Provider → Ollama → 将“API Key”字段**留空**或填入none（部分版本接受此值），保存后重启Cursor。
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
【关键提醒】一旦填入任意非空字符串，Cursor就会强制在所有请求头中注入Authorization字段，Ollama原生服务无法解析，必报401。
验证并重置本地Ollama身份凭据
第一步：检查公钥是否存在
macOS/Linux终端执行：ls -la ~/.ollama/id_*.pub
Windows PowerShell执行：dir "$env:USERPROFILE\.ollama\id_*.pub"
第二步：若文件存在但权限宽松（如644），执行chmod 600 ~/.ollama/id_ed25519.pub（macOS/Linux）或右键属性→安全→仅当前用户有读取权限（Windows）。
第三步：若文件缺失或损坏，运行ollama keys generate重建密钥对。这一步会覆盖旧密钥，所有已绑定该密钥的远程操作（如push）需重新授权。
第四步：执行ollama login重新登录账户。即使你只用本地模型，登录动作会刷新本地会话令牌，修复因长期未操作导致的凭据失效问题。
