Simon Willison
1 个来源llm-keys-ui 0.1 发布
llm-keys-ui 0.1 是一个新插件，提供网页界面，用于将 API 密钥保存到机器上，而无需直接粘贴到代理会话中。它专为 Codex Remote 和 LLM 项目设计，之后可通过 `llm keys get anthropic` 等命令获取密钥。
返回信息流
新闻事件
SynthePulse Insight · AI 深度解读
把 API 密钥从聊天窗口里拿出来：llm-keys-ui 0.1 想解决的一个小问题
版本 1 · 1 个来源
Simon Willison 发布 llm-keys-ui 0.1，一个用于在 Web 界面中设置 LLM API 密钥的插件。它的出发点不是功能扩张，而是回避一个具体动作：不要把密钥粘贴进 agent 会话。
- llm-keys-ui 0.1 于 2026 年 9 月 20 日发布，定位是“用于设置密钥的 LLM Web UI”。
- 作者的使用场景是：用 Codex Remote 在远程机器上跑编码 agent，同时从手机上控制它们。
- 触发需求的动作是配置 API 密钥，作者明确表示不喜欢把 API 密钥粘贴进 agent 会话。
- 使用方式是让 Codex 执行 uvx --with llm-keys-ui llm keys-ui --all，再由它告知访问 URL。
- 该 URL 包含局域网或 Tailscale 设备 IP，指向一个可保存额外 API 密钥的界面。
- 后续可通过 llm keys get anthropic 这类命令在 shell 中取用密钥。
展开章节目录一个被明确限定的问题
一个被明确限定的问题
llm-keys-ui 0.1 的发布说明开门见山地承认，这个插件“解决的是一个非常具体的问题”。它没有被包装成通用密钥管理方案，而是一个 LLM Web UI，用途就是在界面上设置密钥。
问题的来源是作者自己的工作流：他开始使用 Codex Remote 在多台机器上运行编码 agent，并从手机上进行控制。当这些机器被用来做 LLM 相关项目时，偶尔就需要配置 API 密钥——这正是插件要处理的环节。
为什么不是直接粘贴
作者给出的理由是一条个人偏好，而非安全审计结论：他不喜欢把 API 密钥粘贴进 agent 会话。因此他想要一条路径，能把密钥送到机器上，同时又不经过 ChatGPT 应用直接粘贴。
这里需要区分事实与推断。不喜欢粘贴密钥、以及希望绕开 ChatGPT 应用直接粘贴，是发布说明中作者自述的动机，属于来源陈述；至于这一做法是否在客观上降低了密钥泄露风险，来源并未给出验证或评估，不能当作已确认的结论。
操作路径：一条命令、一个 URL、一次取用
发布说明给出的操作方式很简短。作者可以让 Codex 运行 uvx --with llm-keys-ui llm keys-ui --all，然后让 Codex 告诉他访问 URL；这个 URL 包含局域网或 Tailscale 设备 IP，指向一个用于保存额外 API 密钥的界面。
密钥写入之后，后续可以在 shell 命令中使用类似 llm keys get anthropic 的写法来取用密钥。整个流程把“写入密钥”和“在命令中读取密钥”拆成了两个动作，中间由 Web 界面承担输入环节。
边界与不确定性
目前可确认的信息仅限于发布说明本身：版本号 0.1、发布时间 2026 年 9 月 20 日、插件定位、使用命令与 URL 形态。来源没有提供密钥的存储方式、加密机制、访问控制细节，也没有第三方验证或安全评估。
因此，把它理解为“一种避免在 agent 会话中粘贴密钥的操作习惯工具”是来源支持的；把它理解为“经过验证的安全方案”则超出了来源范围。后者只能作为待验证的问题保留。
可信度边界
本文全部依据单一来源：Simon Willison 于 2026 年 9 月 20 日发布的 llm-keys-ui 0.1 发布说明。该来源为作者本人对自研插件的介绍，属于第一方陈述，但涉及动机与使用体验的部分仍是主观自述；来源未提供密钥存储、加密或访问控制的任何技术细节，也无第三方验证。文中凡涉及“降低风险”一类判断均未采用，因为来源不支持。
核心结论
llm-keys-ui 0.1 的价值不在于新增能力，而在于把“配置 API 密钥”从 agent 会话里挪到一个由局域网或 Tailscale 可达的 Web 界面中；它是否更安全，来源没有回答，只回答了作者不想怎么用。
主报道
Simon Willison
主报道来源