Sublime Text 官方不支持 GitHub Copilot，因其API限制多、缺乏LSP原生集成，且微软未投入适配资源；所有所谓“接入”方案均失效或需非官方代理，实际障碍包括认证失败、token过期快、响应格式变更及严格限流。
Sublime Text 目前无法安装 GitHub Copilot，官方从未提供支持，所有声称“成功接入 Copilot”的方案都依赖非官方代理、逆向接口或已失效的第三方插件（如 copilot-subl），且自 2023 年底起基本全部不可用。
为什么 GitHub Copilot 不支持 Sublime Text？
GitHub 官方只发布了 VS Code、JetBrains 系列（IntelliJ、PyCharm 等）、Visual Studio 和 Neovim 的正式插件。Sublime Text 的 API 限制多、缺乏语言服务器协议（LSP）原生深度集成能力，且微软未投入资源适配——这不是配置问题，而是根本没这个产品。
常见误解来源：
- 看到过时博客里
copilot-subl插件截图（该仓库已于 2023 年归档，POST /copilot/autocomplete接口已强制鉴权并关闭匿名调用） - 误把
TabNine或CodeWhisperer的 Sublime 支持当成 Copilot - 尝试用
curl手动调用 Copilot 后端——返回401 Unauthorized或403 Forbidden，因需 GitHub App OAuth token + 严格 User-Agent + 会话绑定
Sublime Text 中可用的 AI 辅助替代方案
虽然不能用 Copilot，但可通过以下方式获得接近的补全体验（注意：均不访问 GitHub 后端，数据不出本地或走独立服务商）：
-
TabNine：支持 Sublime Text，本地模型可选（tabnine.com提供 Sublime 插件，安装后启用Enable Local Model可离线运行） -
CodeWhisperer（AWS）：官方未支持 Sublime，但可通过SublimeLSP+ 自建代理桥接（需自行部署codewhisperer-lsp-proxy，稳定性差，不推荐日常使用） -
Continue.dev：开源 LSP 客户端，支持 Sublime（需手动配置LSP-Continuedev插件），后端可连本地 Ollama 模型（如codellama:7b），无网络依赖
推荐路径：
Package Control → Install Package → TabNine，安装后重启，它会自动下载轻量模型，补全触发键为
Tab 或 Enter（可在 Preferences → Package Settings → TabNine → Settings 中调整）。
硬要“对接 Copilot”会遇到什么实际障碍？
即使你找到某个脚本或 fork 版本，也会立刻卡在这些环节：
- 认证失败：Copilot 现在强制要求
github.com/login/oauth/authorize流程，Sublime 无 WebView 组件，无法完成登录跳转 - Token 过期快：临时 token 有效期约 1 小时，且绑定设备指纹，无法持久化保存
- 补全响应格式变更：Copilot API 返回结构已从纯文本改为带
completion/displayText/range的 JSON，旧插件解析逻辑全部失效 - Rate Limit 极严：未授权调用直接
429 Too Many Requests，连调试请求都发不出三次
真正想用 Copilot，唯一可靠路径是换编辑器——VS Code 是唯一零配置、持续更新、支持登录/结对编程/解释代码的环境。Sublime 的优势在于启动快、轻量、正则替换强，但它不是 AI 编程时代的主力载体。
别在兼容性上耗时间，AI 补全对编辑器的底层依赖（LSP 支持、异步网络、UI 扩展能力）已经拉开代际差距。能跑 TabNine 就不错了，真要 Copilot 级体验，就得接受它的运行容器。
