Add agent tool installation notes
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: 使用 mamba 和 npm 安装 Claude Code
|
||||
date: 2026-05-26
|
||||
tags: [Claude Code, Node.js, npm, mamba]
|
||||
collections: [软件安装]
|
||||
summary: 记录使用 mamba 准备 Node.js 环境并通过 npm 安装 Claude Code 的基本流程。
|
||||
draft: false
|
||||
featured: false
|
||||
---
|
||||
|
||||
# 使用 mamba 和 npm 安装 Claude Code
|
||||
|
||||
这篇笔记整理了一次 Claude Code 的安装过程,适合已经在本机使用 `mamba` 管理环境的场景。
|
||||
|
||||
## 创建 Node.js 环境
|
||||
|
||||
先创建一个独立环境,再在其中安装 `nodejs`。
|
||||
|
||||
```bash
|
||||
mamba create -n node
|
||||
mamba activate node
|
||||
|
||||
mamba install nodejs
|
||||
```
|
||||
|
||||
## 使用 npm 安装 Claude Code
|
||||
|
||||
环境准备完成后,可以直接通过 `npm` 全局安装。
|
||||
|
||||
```bash
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
```
|
||||
|
||||
## 网络较慢时切换镜像
|
||||
|
||||
如果安装过程中遇到网络问题,可以临时切换 npm registry 进行加速,安装完成后再切回官方源。
|
||||
|
||||
```bash
|
||||
npm config set registry https://registry.npmmirror.com
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
npm config set registry https://registry.npmjs.org
|
||||
```
|
||||
|
||||
## 跳过首次启动引导
|
||||
|
||||
安装完成后,如果希望跳过首次启动时的引导和登录检查,可以在 `~/.claude.json` 中写入下面的内容:
|
||||
|
||||
```json
|
||||
{
|
||||
"hasCompletedOnboarding": true,
|
||||
"hasTrustDialogAccepted": true,
|
||||
"primaryApiKey": "sk-placeholder"
|
||||
}
|
||||
```
|
||||
|
||||
## 说明
|
||||
|
||||
上面的配置示例使用占位符形式的 `primaryApiKey`。实际使用时,按自己的认证方式和运行需求调整即可。
|
||||
@@ -0,0 +1,408 @@
|
||||
---
|
||||
title: Codex CLI 安装、配置与常用方法
|
||||
date: 2026-05-26
|
||||
tags: [Codex, OpenAI, CLI, AI 编程]
|
||||
collections: [软件安装]
|
||||
summary: 基于 2026-05-26 检索到的 OpenAI 官方文档,整理使用 mamba 准备 Node.js 环境后安装 Codex CLI 的流程、配置文件写法和常用操作。
|
||||
draft: false
|
||||
featured: false
|
||||
---
|
||||
|
||||
# Codex CLI 安装、配置与常用方法
|
||||
|
||||
这篇笔记基于 2026-05-26 检索到的 OpenAI 官方文档整理,目标是把 Codex CLI 的安装、配置文件和常用操作一次讲清楚。考虑到我自己更习惯用 `mamba` 管理本地 Node.js 环境,下面先保留这条安装路径,再接官方的 npm 安装步骤。原始草稿里那种把真实密钥直接写进配置文件的做法不适合保留,正式使用时应当改成环境变量或官方登录方式。
|
||||
|
||||
## 安装 Codex CLI
|
||||
|
||||
### 使用 mamba 准备 Node.js 环境
|
||||
|
||||
如果你平时用 `mamba` 管理开发环境,可以先单独准备一个 Node.js 环境,再在这个环境里安装 Codex CLI:
|
||||
|
||||
```bash
|
||||
mamba create -n node nodejs -y
|
||||
mamba activate node
|
||||
```
|
||||
|
||||
如果你已经有可用的 Node.js 环境,可以直接跳到下一步。
|
||||
|
||||
### 使用 npm 安装 Codex CLI
|
||||
|
||||
OpenAI 官方文档给出的 npm 安装命令如下:
|
||||
|
||||
```bash
|
||||
npm i -g @openai/codex
|
||||
```
|
||||
|
||||
安装完成后直接运行:
|
||||
|
||||
```bash
|
||||
codex
|
||||
```
|
||||
|
||||
第一次启动时,Codex 会提示登录。官方也给出了升级命令:
|
||||
|
||||
```bash
|
||||
npm i -g @openai/codex@latest
|
||||
```
|
||||
|
||||
如果你只是想先确认 CLI 是否已经可用,最直接的方式就是运行 `codex` 看是否能进入交互界面。
|
||||
|
||||
## 登录方式
|
||||
|
||||
Codex 官方支持两种主要认证方式:
|
||||
|
||||
1. 使用 ChatGPT 账号登录,适合日常交互式使用。
|
||||
2. 使用 API key 登录,适合按量计费和自动化场景。
|
||||
|
||||
### 使用 ChatGPT 登录
|
||||
|
||||
对 CLI 来说,默认登录路径是 ChatGPT 登录。运行 `codex` 或显式执行下面的命令后,Codex 会打开浏览器完成登录流程:
|
||||
|
||||
```bash
|
||||
codex login
|
||||
```
|
||||
|
||||
这种方式更适合个人日常使用,因为它直接走 ChatGPT 账号授权流程。
|
||||
|
||||
### 使用 API key 登录
|
||||
|
||||
如果你更关心脚本化、CI/CD 或明确的 API 计费路径,可以改用 API key。官方建议把 API key 用在程序化工作流中,而不是写死在配置文件里。
|
||||
|
||||
```bash
|
||||
export OPENAI_API_KEY="sk-..."
|
||||
printenv OPENAI_API_KEY | codex login --with-api-key
|
||||
```
|
||||
|
||||
### 无图形界面环境
|
||||
|
||||
如果是在远程服务器、无浏览器环境或者本地回调被网络策略拦截,可以使用设备码登录:
|
||||
|
||||
```bash
|
||||
codex login --device-auth
|
||||
```
|
||||
|
||||
## 配置文件位置与优先级
|
||||
|
||||
Codex 的用户级配置文件位于 `~/.codex/config.toml`。如果希望只对某个仓库生效,可以在项目中添加 `.codex/config.toml`。
|
||||
|
||||
官方文档给出的配置优先级从高到低是:
|
||||
|
||||
1. CLI 参数和 `--config` 覆盖。
|
||||
2. `--profile <name>` 指定的 profile。
|
||||
3. 项目级 `.codex/config.toml`。
|
||||
4. 用户级 `~/.codex/config.toml`。
|
||||
5. 系统级配置。
|
||||
6. 内置默认值。
|
||||
|
||||
需要注意的是,一些与机器本地环境强绑定的键不适合放在项目级配置里。像 `model_provider`、`model_providers`、`profiles`、`openai_base_url` 和 `chatgpt_base_url` 这类字段,官方明确要求放在用户级配置中。
|
||||
|
||||
## 一份适合日常使用的配置
|
||||
|
||||
如果你主要是在本机交互式写代码,下面这份配置已经够用:
|
||||
|
||||
```toml
|
||||
model = "gpt-5.5"
|
||||
model_reasoning_effort = "medium"
|
||||
plan_mode_reasoning_effort = "high"
|
||||
|
||||
approval_policy = "on-request"
|
||||
sandbox_mode = "workspace-write"
|
||||
web_search = "cached"
|
||||
|
||||
cli_auth_credentials_store = "keyring"
|
||||
|
||||
[projects."/path/to/project"]
|
||||
trust_level = "trusted"
|
||||
```
|
||||
|
||||
这份配置的含义很直接:
|
||||
|
||||
- `model` 指定默认模型。官方示例给大多数用户推荐的是 `gpt-5.5`。
|
||||
- `model_reasoning_effort` 控制默认推理强度,可选值包括 `minimal`、`low`、`medium`、`high` 和 `xhigh`。
|
||||
- `plan_mode_reasoning_effort` 控制计划模式下的推理强度,适合在 `/plan` 时单独拉高。
|
||||
- `approval_policy = "on-request"` 表示由 Codex 决定何时向你申请批准,适合多数交互式场景。
|
||||
- `sandbox_mode = "workspace-write"` 表示允许在当前工作区写文件,但不是完全放开机器权限。
|
||||
- `web_search = "cached"` 表示默认启用缓存型网页搜索;如果要查最新资料,可以临时改成 `--search` 或把配置改成 `live`。
|
||||
- `cli_auth_credentials_store = "keyring"` 表示尽量把登录凭据放进系统密钥链,而不是纯文件。
|
||||
- `trust_level = "trusted"` 表示把这个仓库标记为可信项目,这样项目级 `.codex/` 配置、rules 和 hooks 才会生效。
|
||||
|
||||
## 配置项详解
|
||||
|
||||
下面这些字段是最常用、也最值得理解的。
|
||||
|
||||
### `model`
|
||||
|
||||
`model` 决定 Codex 默认调用哪个模型。OpenAI 官方示例里推荐大多数用户使用 `gpt-5.5`;如果你更想显式指定编码导向模型,也可以改成例如 `gpt-5.3-codex`。
|
||||
|
||||
```toml
|
||||
model = "gpt-5.5"
|
||||
```
|
||||
|
||||
### `model_provider`
|
||||
|
||||
`model_provider` 指向 `[model_providers]` 中的某个 provider id。默认 provider 是 `openai`。
|
||||
|
||||
```toml
|
||||
model_provider = "openai"
|
||||
```
|
||||
|
||||
如果你没有自建代理、Azure 或本地模型需求,通常不需要改它。
|
||||
|
||||
### `model_reasoning_effort`
|
||||
|
||||
这个字段控制模型的推理强度,适合在速度和深度之间做平衡。
|
||||
|
||||
```toml
|
||||
model_reasoning_effort = "medium"
|
||||
```
|
||||
|
||||
一般可以这样理解:
|
||||
|
||||
- `low` 或 `medium` 适合日常改代码、解释报错、补文档。
|
||||
- `high` 或 `xhigh` 更适合复杂重构、跨文件问题定位和方案分析。
|
||||
|
||||
### `plan_mode_reasoning_effort`
|
||||
|
||||
这是计划模式专用的推理强度覆盖项。也就是说,平时对话可以用 `medium`,但在 `/plan` 阶段单独切到 `high`。
|
||||
|
||||
```toml
|
||||
plan_mode_reasoning_effort = "high"
|
||||
```
|
||||
|
||||
### `approval_policy`
|
||||
|
||||
官方支持三种主模式:
|
||||
|
||||
- `untrusted`:只自动执行已知安全的只读命令,其他操作更谨慎。
|
||||
- `on-request`:由 Codex 决定何时请求批准。
|
||||
- `never`:尽量不询问,风险最高。
|
||||
|
||||
```toml
|
||||
approval_policy = "on-request"
|
||||
```
|
||||
|
||||
如果是个人机器上的正常开发工作流,`on-request` 通常最稳妥。
|
||||
|
||||
### `sandbox_mode`
|
||||
|
||||
这个字段控制 Codex 执行命令时的沙箱范围:
|
||||
|
||||
- `read-only`
|
||||
- `workspace-write`
|
||||
- `danger-full-access`
|
||||
|
||||
```toml
|
||||
sandbox_mode = "workspace-write"
|
||||
```
|
||||
|
||||
通常建议从 `workspace-write` 起步,不要一开始就切到 `danger-full-access`。
|
||||
|
||||
### `default_permissions`
|
||||
|
||||
新权限体系可以用 `default_permissions` 指向命名权限配置,官方内置了:
|
||||
|
||||
- `:read-only`
|
||||
- `:workspace`
|
||||
- `:danger-full-access`
|
||||
|
||||
```toml
|
||||
default_permissions = ":workspace"
|
||||
```
|
||||
|
||||
官方文档特别提醒,不要把这套权限配置和旧式的 `sandbox_mode` 混着用。二选一即可。
|
||||
|
||||
### `web_search`
|
||||
|
||||
Codex 自带第一方网页搜索工具,顶层配置支持:
|
||||
|
||||
- `disabled`
|
||||
- `cached`
|
||||
- `live`
|
||||
|
||||
```toml
|
||||
web_search = "cached"
|
||||
```
|
||||
|
||||
如果你查的是版本更新、价格、新闻或最近发布内容,改成 `live` 更合适。
|
||||
|
||||
### `review_model`
|
||||
|
||||
如果你经常在交互界面里使用 `/review`,可以单独给 review 指定模型:
|
||||
|
||||
```toml
|
||||
review_model = "gpt-5.5"
|
||||
```
|
||||
|
||||
不配置时,默认沿用当前会话模型。
|
||||
|
||||
### `cli_auth_credentials_store`
|
||||
|
||||
这个字段决定 CLI 如何保存登录凭据:
|
||||
|
||||
- `file`
|
||||
- `keyring`
|
||||
- `auto`
|
||||
|
||||
```toml
|
||||
cli_auth_credentials_store = "keyring"
|
||||
```
|
||||
|
||||
如果本机系统支持密钥链,优先用 `keyring` 或 `auto` 更合理。
|
||||
|
||||
## 自定义 provider 的正确写法
|
||||
|
||||
原始草稿里把真实密钥直接写进 TOML,这种方式不应该继续使用。官方给出的思路是:
|
||||
|
||||
1. 如果底层仍然使用 OpenAI 身份认证,就设置 `requires_openai_auth = true`。
|
||||
2. 如果底层需要单独的 provider key,就设置 `env_key = "YOUR_ENV_VAR"`。
|
||||
3. `wire_api` 目前只支持 `responses`。
|
||||
|
||||
### 场景一:代理后端仍然走 OpenAI 登录
|
||||
|
||||
```toml
|
||||
model = "gpt-5.3-codex"
|
||||
model_provider = "proxy-openai"
|
||||
|
||||
[model_providers.proxy-openai]
|
||||
name = "OpenAI Proxy"
|
||||
base_url = "https://your-proxy.example.com/v1"
|
||||
wire_api = "responses"
|
||||
requires_openai_auth = true
|
||||
```
|
||||
|
||||
这种写法的重点是:既然已经使用 OpenAI 认证,就不要再写 `env_key`,因为官方文档明确说明 `requires_openai_auth = true` 时会忽略 `env_key`。
|
||||
|
||||
### 场景二:第三方兼容端点使用环境变量认证
|
||||
|
||||
```toml
|
||||
model = "gpt-5.3-codex"
|
||||
model_provider = "compatible-api"
|
||||
|
||||
[model_providers.compatible-api]
|
||||
name = "Compatible API"
|
||||
base_url = "https://api.example.com/v1"
|
||||
wire_api = "responses"
|
||||
env_key = "COMPATIBLE_API_KEY"
|
||||
env_key_instructions = "export COMPATIBLE_API_KEY=..."
|
||||
```
|
||||
|
||||
这里的 `env_key` 写的是环境变量名,不是密钥本身。
|
||||
|
||||
## 常用方法
|
||||
|
||||
Codex 真正常用的不是“装完能启动”,而是下面这些操作。
|
||||
|
||||
### 进入交互式会话
|
||||
|
||||
最常见的用法就是直接启动:
|
||||
|
||||
```bash
|
||||
codex
|
||||
```
|
||||
|
||||
如果启动时顺便给一句任务,也可以这样写:
|
||||
|
||||
```bash
|
||||
codex "Explain this repository structure"
|
||||
```
|
||||
|
||||
### 附带图片一起提问
|
||||
|
||||
CLI 支持把截图或设计图一起传给 Codex:
|
||||
|
||||
```bash
|
||||
codex -i screenshot.png "Explain this error"
|
||||
```
|
||||
|
||||
多张图片也可以一起传:
|
||||
|
||||
```bash
|
||||
codex -i img1.png -i img2.jpg "Summarize these diagrams"
|
||||
```
|
||||
|
||||
### 查询最新网页信息
|
||||
|
||||
官方文档说明,Codex CLI 默认可以使用缓存搜索;如果你需要最新信息,可以显式开启 live web search:
|
||||
|
||||
```bash
|
||||
codex --search "Check the latest release notes for this library"
|
||||
```
|
||||
|
||||
### 非交互脚本化运行
|
||||
|
||||
如果要把 Codex 接进脚本或流水线,核心命令是 `codex exec`:
|
||||
|
||||
```bash
|
||||
codex exec "summarize the repo structure"
|
||||
```
|
||||
|
||||
如果下游程序要消费结构化事件流,可以输出 JSON Lines:
|
||||
|
||||
```bash
|
||||
codex exec --json "summarize the repo structure" | jq
|
||||
```
|
||||
|
||||
还可以用 JSON Schema 限定最终输出格式,这对自动化很实用。
|
||||
|
||||
### 续跑上一次任务
|
||||
|
||||
非交互任务跑到一半后,如果你想接着上一轮继续做,可以使用 `resume`:
|
||||
|
||||
```bash
|
||||
codex exec "review the change for race conditions"
|
||||
codex exec resume --last "fix the race conditions you found"
|
||||
```
|
||||
|
||||
### Git 仓库保护
|
||||
|
||||
官方文档说明,`codex exec` 默认要求在 Git 仓库内运行,以降低误操作风险。只有在你明确知道环境安全时,才建议跳过这个检查:
|
||||
|
||||
```bash
|
||||
codex exec --skip-git-repo-check "summarize files in this directory"
|
||||
```
|
||||
|
||||
### 交互模式下最值得记住的 slash commands
|
||||
|
||||
下面这些命令最常用:
|
||||
|
||||
- `/model`:切换模型和推理强度。
|
||||
- `/plan`:先让 Codex 给出计划,再决定是否进入执行。
|
||||
- `/permissions`:动态调整当前会话的审批和权限级别。
|
||||
- `/review`:让 Codex 检查当前工作区改动,优先指出风险和遗漏测试。
|
||||
- `/diff`:查看当前工作树的变更。
|
||||
- `/mcp`:检查本次会话可用的 MCP 工具。
|
||||
- `/status`:查看当前模型、权限、上下文容量等状态。
|
||||
- `/theme`:切换终端高亮主题。
|
||||
|
||||
## 一个更稳妥的使用建议
|
||||
|
||||
如果你刚开始用 Codex,建议先采用下面这套组合:
|
||||
|
||||
```toml
|
||||
model = "gpt-5.5"
|
||||
model_reasoning_effort = "medium"
|
||||
approval_policy = "on-request"
|
||||
sandbox_mode = "workspace-write"
|
||||
web_search = "cached"
|
||||
```
|
||||
|
||||
这套配置的特点是:
|
||||
|
||||
- 模型能力足够强。
|
||||
- 推理强度不过高,响应速度更平衡。
|
||||
- 允许写工作区,但不会默认放开整台机器。
|
||||
- 大部分危险动作仍然会停下来让你确认。
|
||||
|
||||
等你熟悉自己的工作流后,再去细调 `plan_mode_reasoning_effort`、`review_model`、`profiles` 和自定义 provider。
|
||||
|
||||
## 参考链接
|
||||
|
||||
- [Codex CLI 官方总览](https://developers.openai.com/codex/cli)
|
||||
- [Codex Authentication](https://developers.openai.com/codex/auth)
|
||||
- [Config basics](https://developers.openai.com/codex/config-basic)
|
||||
- [Configuration Reference](https://developers.openai.com/codex/config-reference)
|
||||
- [Sample Configuration](https://developers.openai.com/codex/config-sample)
|
||||
- [CLI Features](https://developers.openai.com/codex/cli/features)
|
||||
- [Command line options](https://developers.openai.com/codex/cli/reference)
|
||||
- [Slash commands](https://developers.openai.com/codex/cli/slash-commands)
|
||||
- [Non-interactive mode](https://developers.openai.com/codex/noninteractive)
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: 使用 Miniforge 安装 mamba
|
||||
date: 2026-05-26
|
||||
tags: [mamba, Miniforge, conda, Python]
|
||||
collections: [软件安装]
|
||||
summary: 记录通过 Miniforge 安装 mamba 的基本方法,并补充几个装完后最常用的命令。
|
||||
draft: false
|
||||
featured: false
|
||||
---
|
||||
|
||||
# 使用 Miniforge 安装 mamba
|
||||
|
||||
如果只是想快速开始使用 `mamba`,现在最直接的方式通常不是单独找一个 `mamba` 安装包,而是先安装 `Miniforge`。根据 conda-forge 官方下载页,`Miniforge` 是当前推荐的安装器,默认已经包含 `conda`、`mamba` 及其依赖。
|
||||
|
||||
## 下载 Miniforge
|
||||
|
||||
官方发布页在这里:
|
||||
|
||||
<https://github.com/conda-forge/miniforge/releases>
|
||||
|
||||
按自己的系统和架构选择对应安装包即可,例如 macOS 分为 Apple Silicon 和 Intel,Linux 也区分 `x86_64` 与 `aarch64`。
|
||||
|
||||
## 命令行安装
|
||||
|
||||
如果是在 macOS、Linux 或 WSL 环境中,官方 README 给出了这种命令行安装方式:
|
||||
|
||||
```bash
|
||||
curl -L -O "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh"
|
||||
bash Miniforge3-$(uname)-$(uname -m).sh
|
||||
```
|
||||
|
||||
安装过程中会提示是否初始化 shell。一般按推荐设置即可,安装完成后重新打开终端,或者手动加载初始化脚本。
|
||||
|
||||
## 为什么优先选 Miniforge
|
||||
|
||||
conda-forge 官方下载页明确说明,`Miniforge` 是推荐安装器,并且已经内置 `mamba`。Miniforge README 还提到,`Mambaforge` 已经退役,当前更建议直接使用 `Miniforge3`。
|
||||
|
||||
如果你只是为了更快地创建环境和安装包,那么直接装 `Miniforge` 就够了。
|
||||
|
||||
## 安装后最常用的命令
|
||||
|
||||
`mamba` 的命令风格和 `conda` 基本一致。官方用户手册给出的最常见用法如下。
|
||||
|
||||
### Linux 下先初始化 shell
|
||||
|
||||
在 Linux 上,安装完 `Miniforge` 之后,通常还需要先做一次 shell 初始化,否则新开的终端里可能无法直接使用 `mamba activate`。`conda init` 官方命令支持 `bash`、`zsh`、`fish` 等 shell,在 Linux 上默认最常见的是:
|
||||
|
||||
```bash
|
||||
conda init bash
|
||||
source ~/.bashrc
|
||||
```
|
||||
|
||||
如果你用的是 `zsh`,则改成:
|
||||
|
||||
```bash
|
||||
conda init zsh
|
||||
source ~/.zshrc
|
||||
```
|
||||
|
||||
`mamba` 官方文档也说明了,`mamba` 与 `conda` 使用相同的命令和配置体系,因此这里的初始化步骤直接沿用 `conda init` 即可。
|
||||
|
||||
### 关闭默认激活 `base`
|
||||
|
||||
很多人不希望每次打开终端都自动进入 `base` 环境。`conda` 配置文档里把这个行为叫作 `auto_activate_base`,可以这样关闭:
|
||||
|
||||
```bash
|
||||
conda config --set auto_activate_base false
|
||||
```
|
||||
|
||||
设置完成后,重新打开终端时就不会默认激活 `base` 了。需要时再手动执行:
|
||||
|
||||
```bash
|
||||
mamba activate myenv
|
||||
```
|
||||
|
||||
### 创建环境
|
||||
|
||||
```bash
|
||||
mamba create -n myenv python=3.12
|
||||
```
|
||||
|
||||
### 激活环境
|
||||
|
||||
```bash
|
||||
mamba activate myenv
|
||||
```
|
||||
|
||||
### 安装软件包
|
||||
|
||||
```bash
|
||||
mamba install numpy pandas
|
||||
```
|
||||
|
||||
如果需要显式指定 `conda-forge`:
|
||||
|
||||
```bash
|
||||
mamba create -n myjlabenv jupyterlab -c conda-forge
|
||||
```
|
||||
|
||||
## 关于镜像
|
||||
|
||||
我自己更倾向于先用默认的 conda-forge 源。国内镜像在某些时候确实可能更快,但也可能出现同步不及时或包版本不一致的问题。对多数安装场景来说,先用官方默认配置通常更省事。
|
||||
|
||||
## 小结
|
||||
|
||||
对现在的 `mamba` 安装流程,可以直接记住一句话:先装 `Miniforge`,然后再用 `mamba create`、`mamba activate` 和 `mamba install` 管理环境即可。
|
||||
Reference in New Issue
Block a user