google-docs-mcp

google-docs-mcp

将 Google Docs 作为 MCP 工具。从 Claude 或任何 MCP 客户端读取、编辑、建议修改并评论文档。

这是一个通过标准输入/输出运行 Model Context Protocol 的单一 Go 二进制文件。它作为客户端的子进程在你自己的计算机上运行，并使用你自己的 Google 账号。无需托管服务端、无需共享部署，也无需服务账号：创建一个 Google OAuth 客户端，登录一次，刷新令牌便会保存在操作系统密钥环中。

它像一位细心的同事一样处理文档——以恰当的粒度读取，在原处编辑且不破坏编辑内容周围的部分，将修改作为建议提出，对文段发表评论，并处理表格、标签页、页眉、脚注和格式。

为什么选择 google-docs-mcp

现有服务会将原始 UTF-16 索引交给模型，以可能悄然损坏文档的方式转换 Markdown，并通过 Drive API 锚定评论，导致评论无法内嵌显示。本服务在服务端处理索引计算，按精确文本和稳定的标题 ID 定位内容，通过最小差异进行编辑，拒绝覆盖已锚定的内容，并在项目已启用的情况下使用 Docs API 的建议模式。相关依据和证据见 docs/architecture.md。

已支持读取、搜索、创建、导出、以最小差异进行建议模式、直接模式或评论模式编辑、格式设置、审核建议、评论串、修订历史和差异、表格、标签页、页眉、页脚、脚注、图片、智能芯片、命名范围、页面和分节布局、命名样式、gdocs:// 资源、大型文档性能以及 Agent 评测。Docs API 的 Request 联合类型中所有 GA 成员均已实现；架构文档第 16 节说明了这些工具公开哪些字段，以及有意不公开哪些字段。

安装

go install github.com/mmedum/google-docs-mcp/v3/cmd/google-docs-mcp@latest

这会将 google-docs-mcp 安装到 $(go env GOPATH)/bin，你可以将此路径提供给 MCP 客户端。也可以从最新版本下载已签名的归档文件——支持 Linux、macOS 和 Windows，以及 amd64 和 arm64——并在运行前验证：

tar xzf google-docs-mcp_*_linux_amd64.tar.gz
sha256sum -c checksums.txt --ignore-missing

# The checksum file is signed with a keyless Sigstore certificate tied to
# the release workflow's identity. The bundle carries both.
cosign verify-blob checksums.txt \
  --bundle checksums.txt.bundle \
  --certificate-identity-regexp 'https://github\.com/mmedum/google-docs-mcp/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

# And the archive itself carries build provenance.
gh attestation verify google-docs-mcp_*_linux_amd64.tar.gz --repo mmedum/google-docs-mcp

每个归档文件还包含一份 SBOM（.sbom.json），方便你查看未自行构建的二进制文件包含哪些内容。go install 无需这些步骤：模块代理和 sum.golang.org 会在构建前验证源代码。无论通过哪种方式，google-docs-mcp --version 都会报告对应的发布版本。

设置 Google

每位部署者都使用自己的 Google Cloud 项目和 OAuth 客户端。没有共享应用，也无需通过 Google 验证任何内容。

1. 创建或选择一个 Google Cloud 项目。

2. 启用 Google Docs API 和 Google Drive API （APIs & Services → Library）。

3. 配置 OAuth 同意屏幕（Google Auth Platform → Audience）：

   • 如果你的账号属于 Google Workspace 组织，选择 Internal。 这样令牌就永不过期。
   • 对于个人账号，选择 External，并将发布状态设为 Testing。 将自己添加为测试用户。Google 会在 7 天后让此类应用的刷新令牌过期，因此你需要每周运行一次 login。

4. 添加作用域（Google Auth Platform → Data Access）：.../auth/documents、 .../auth/documents.readonly、.../auth/drive、.../auth/drive.readonly。

   需要添加全部四个作用域，不过一次登录最多只会请求其中两个：普通登录会请求 documents 和 drive，而 GDOCS_READ_ONLY=true 会改为请求 documents.readonly 和 drive.readonly。同意屏幕会列出客户端可能请求的权限，因此必须涵盖两种情况；如果没有获批某个作用域，那么有人首次尝试只读模式时就会被拒绝。Google 只会授予实际请求的权限，因此列出这两个只读作用域不会给普通登录带来任何影响。

5. 创建一个类型为 Desktop app 的 OAuth 客户端（Google Auth Platform → Clients），下载其 JSON 文件，并将其保存为 ~/.config/google-docs-mcp/client_secret.json（Linux；其他系统则保存在操作系统配置目录下的 google-docs-mcp 文件夹中）。 请勿将其放入任何代码仓库。

6. 运行：

google-docs-mcp login
google-docs-mcp doctor https://docs.google.com/document/d/<some doc you can open>/edit

文档是可选的：单独运行 doctor 会检查凭据、作用域和 API 连通性；提供文档时，则会读取该文档。

google-docs-mcp status --json 会在标准输出中以单个 JSON 对象打印相同状态，供需要在启动此服务前判断其是否已获授权的脚本使用。应根据 credentials.resolved 字段进行分支判断；只有在移除字段或其含义发生变化时，schema_version 才会改变；账号会像文本输出中那样，仅显示其域名。人类可读输出中的标签可以在任何版本中重新措辞，但对象结构不会改变。

login 会打开浏览器，在回环端口上完成 Google 桌面 OAuth 流程，并将刷新令牌存入操作系统密钥环（Secret Service、Keychain 或 Credential Manager）；如果没有可用的密钥环，则会在发出警告后改存为权限为 0600 的文件。doctor 会检查每个步骤，并准确告知缺少什么。

通过 SSH 登录

回调会发送到远程主机的回环地址，而你的浏览器在本地，因此必须转发端口。端口随机分配，只会出现在 login 打印的 URL 中，并编码为 127.0.0.1%3A<port>：

google-docs-mcp login --no-browser

从该 URL 中读取端口，在另一个本地终端中转发该端口，然后在自己的浏览器中打开该 URL：

ssh -N -L <port>:127.0.0.1:<port> you@remote-host

如果 ssh 提示 bind: Address already in use，按 Ctrl-C 停止登录，然后重新启动以获取不同的端口。--timeout 用于设置 login 的等待时长；默认值为 5 分钟。

评论和建议

建议模式（mode: suggest）、固定在文本范围上的评论，以及接受或拒绝建议，都使用了 Google 于 2026-09-30 宣布正式推出的 Docs API 功能，推出过程最长持续 15 天。无需注册。如果 Google 拒绝对某篇文档使用这些功能，仍可读取文档；评论会通过 Drive 发布，并引用文本而非固定到文本范围；建议模式则会被拒绝，而不会发送。get_document 会说明具体情况。GDOCS_PREVIEW 已弃用且会被忽略。

Markdown 文件

Docs 会打开存储在 Drive 中的 Markdown 文件（.md，类型为 text/markdown）， 并直接编辑该文件，保留其 Markdown 格式。Docs API 可以读取此类文件，但拒绝所有写入操作；也无法通过打开的编辑器会话写入：唯一的写入方式是上传整个文件，而上传会使打开的编辑器重新加载。因此，有两种方式可以处理这类文件。

一起实时协作：工作副本。 使用 from_file 调用 create_document，即可根据文件创建 Google 文档。你和 Claude 可以像在任何 Google 文档中一样协作：编辑内容会与您的输入合并，建议模式会显示修订痕迹，评论会附在对应段落上。随后，write_markdown_file 会逐块将副本中的更改写回文件。文件其余部分会保留原有 Markdown、前置内容以及 Docs 保存在其中的评论。如果某个块在创建副本后也已在文件中更改，则会产生冲突；除非使用 force 保留文件中的版本，否则写入会被拒绝。

直接编辑文件。 get_document 会返回 kind: markdown_file，读取时返回文件自身的 Markdown 内容；编辑时则只对文本做最小更改，并在每次调用时上传一次：

• 目标可以是精确文本、heading_id（例如 get_outline 中的 slug next-steps）或 heading。行号（L12）相当于 Google 文档中的句柄，长篇读取可从指定位置继续。
• edit_document 支持 insert、append、replace、delete 和 replace_all，并会按给定内容写入。格式、表格、对象、布局和标签页均不支持：请将它们写成 Markdown。
• mode: direct 会更改文本。mode: comment 和 add_comment 会以你的账号名称将评论写入文件，方式与编辑器自行写入评论相同；编辑器会显示该评论，并标记为“From imported document”，保存时也会保留它。每次写入文件后，其 ID 都会改变，直到有人在编辑器中保存文件。 reply_comment 也会以相同方式回复。无法通过文件解决评论（将解决操作写入文件会导致 Google 无法读取文件），因此请在编辑器中解决。Markdown 文件不支持建议。
• 读取时会忽略 Docs 保存在文件中的评论，编辑时不会触及这些评论；list_comments 会列出这些评论以及通过 Drive API 添加的评论。包含评论标记的内容会被拒绝。
• 与 Google 文档一样，除非使用强制选项，否则保护机制会拒绝更改带评论的文本、图片或脚注引用的直接编辑。
• 有人打开文件时写入。 Drive 无法有条件地上传文件，而打开的编辑器中可能有文件尚未显示的更改。写入前，服务会比较编辑器的实时会话与文件：如果评论、回复或解决操作尚未写入文件，服务会稍作等待，然后拒绝写入，无论是否使用 force：这些更改尚未进入任何修订版本。上传前一刻，服务会再次检查。上传后，服务会检查文件历史记录：如果期间有人保存了文件，该保存会被保留，并会在其基础上重新应用更改。
• 用户在 Docs 编辑器中保存文件时，Docs 会用自己的 Markdown 样式重写整个文件，并将前置内容转换为标题。读取时会针对前置内容发出警告；list_revisions 和带有 revision 的 read_document 可以获取较早的文本。
• search_documents 会通过 kind: markdown_file 或 any 查找 Markdown 文件；默认情况下只搜索 Google 文档。使用 kind: markdown_file 调用 create_document 会创建新的 Markdown 文件。

Word 文件

Docs 会打开存储在 Drive 中的 Word 文件（.docx），并原地编辑，保留其 Word 文件格式。Docs API 可以读取文件，将修订内容作为建议、将评论作为评论读取，但会拒绝所有写入操作。因此，此服务会自行写入文件：get_document 会显示 kind: word_file，读取操作与 Google Doc 相同（包括处理内容），而编辑则会修改文件的 XML，并通过 Drive 上传整个文件。

• edit_document 可对正文文本执行 insert、append、replace、delete 和 replace_all 操作，定位方式与 Google Doc 相同；如果匹配项位于页眉、页脚或脚注中，replace_all 会保留该匹配项，并给出警告。在段落内部替换文本时，只会更改最小差异部分，并保留原有格式；涉及多个段落的内容会插入段落之间，或替换整个段落。标题会采用文件自身的标题样式，列表会延续插入位置所在的列表，可通过 list_level 设置层级。
• mode: suggest 会以你的账户名添加 Word 修订，Docs 会将其显示为建议，Word 则显示为修订。mode: direct 会直接更改文本。mode: comment 和 add_comment 会添加 Word 评论。list_comments 会列出评论；回复、解决或删除评论需在 Docs 编辑器中完成。
• 格式设置、表格、图片、版式、标签页以及审核建议等操作会被拒绝，并说明原因：如需执行这些操作，请将文件另存为 Google Doc（文件 > 另存为 Google Docs）。
• 保护机制与 Google Doc 相同：除非强制执行，否则如果直接编辑会删除带评论的文本、建议、图片或脚注引用，操作就会被拒绝。
• 在他人打开文件时写入。 每次写入都会检查 Docs 与文件在涉及的每个段落上是否仍一致；等待后，如果两者不一致，就会拒绝操作。上传前会再次检查，上传后还会检查文件历史记录：如果期间有保存操作，系统会还原该保存内容，并且不应用此次写入。已打开文件的编辑器会重新加载文件。随后，写入操作会等待 Docs 读取新版本。

连接客户端

Claude Code：

claude mcp add --transport stdio google-docs -- google-docs-mcp

Claude Desktop（claude_desktop_config.json）或 Cursor（mcp.json）：

{
  "mcpServers": {
    "google-docs": {
      "command": "/absolute/path/to/google-docs-mcp",
      "env": { "GDOCS_LOG_LEVEL": "info" }
    }
  }
}

Claude Desktop 运行时会根据自身状态重写 claude_desktop_config.json，并丢弃在后台对文件所做的编辑：请先完全退出，再编辑文件，最后重新启动。它还会延迟加载工具定义，因此请稍等片刻，再在聊天中使用工具。

Claude Desktop 也可以直接打开发行版中的 .mcpb 捆绑包，无需编辑配置文件。它会要求填写相同的设置：OAuth 客户端 JSON（可留空以使用已记录的 login）、配置文件、只读模式、默认写入模式、是否删除评论和标签页（enable_destructive），以及导出文件夹（export_dir）。除非手动启用，否则删除功能保持关闭；在选择文件夹前，二进制文件导出也会保持关闭。此服务不会在调用前征求任何人的同意。Claude Desktop 会在每次使用工具时请求批准，可选择“允许一次”或“始终允许”；如果将某个工具设为始终允许，之后调用时就不会再询问，因此除非需要使用相关工具，否则请将 enable_destructive 保持关闭。该捆绑包支持 macOS 和 Linux 的两种架构，也支持使用 amd64 二进制文件的 Windows；Windows arm64 会通过模拟运行。它不会为你登录：还需安装该二进制文件，运行一次 google-docs-mcp login，捆绑包随后会使用相同的凭据。

所有设置均为环境变量；请参阅 docs/configuration.md。默认设置无需额外配置。

工具

工具	功能
get_document	标题、标签页、修订 ID、所有者、上次修改时间、计数，以及此服务的功能（可用的写入模式、默认模式）。此外，还会报告每个标签页的页面设置、浮动对象、命名范围，以及段落所用的命名样式定义——这些信息都无法通过读取文本获取。调用成本低；请先调用。
get_outline	每个标签页的标题树，包含稳定的 heading_id、区块句柄和章节大小。
read_document	按范围和预算读取内容，格式可选 Markdown、纯文本或原始 Docs JSON。可按 heading_id、标题文本、句柄范围、标签页或页眉／页脚／脚注指定范围。除非 with_handles 为 false，否则文本中会包含区块句柄；选项还可添加样式、待处理建议（显示为 {++插入内容++}／{--删除内容--}／{==重设样式内容==}）和评论标记 {>>c:id<<}。
find_in_document	搜索文本或正则表达式，并返回句柄、偏移量和上下文。
search_documents	按标题或内容、所有者或修改日期查找文档；kind 还会包含 Markdown 文件。
export_document	将 Google 自带的 md、txt、html 格式内联导出；pdf、docx、odt、rtf、epub 则作为新文件写入 GDOCS_EXPORT_DIR，绝不覆盖其中已有文件。
create_document	新建文档，可选使用 Markdown 内容；kind: markdown_file 会创建 .md 文件，from_file 则会创建其工作副本。
edit_document	执行一批 insert、append、replace（最小差异）、delete、replace_all（文本或 RE2 正则表达式）、insert_break、insert_footnote、create_header、create_footer、delete_header、delete_footer、create_named_range、delete_named_range、replace_named_range 操作。目标可以是精确文本、heading_id、句柄、单元格或命名范围；命名范围在后续编辑中仍然有效。Markdown 内容可以包含表格和图片；文本写入后，后续批次会放置这些内容；其中的列表会延续其所放置位置对应的列表项，除非 list_level 指定了级别。支持 mode: suggest、direct 或 comment；dry_run；expect_revision；force。
format_document	对相同目标应用 text_style、paragraph_style、bullets、clear_formatting，并支持相同模式。链接可指向 URL、同一标签页中的标题（#h.…，来自 get_outline），或某个标签页（#tab=t.…）；Markdown 内容支持相同形式。
list_suggestions	列出待处理的建议编辑，包含 ID、文本和句柄；也包括没有添加或删除任何内容、仅修改格式的建议，以及每条建议讨论串中的回复。
review_suggestion	接受、拒绝或丢弃建议；每项操作均使用 list_suggestions 显示的 ID。
list_comments	列出评论讨论串及其所有回复、已解决和已删除状态、分配对象、引用文本和所在区块。
add_comment	对一段内容发表评论（固定在该内容上），或对文档发表评论；对于 Markdown 文件，评论会写入文件。
reply_comment	回复讨论串、解决或重新打开讨论串，或改写你自己的评论或回复。也可回复建议编辑的讨论串。
list_revisions	版本历史：修订 ID、时间和作者。
diff_revisions	两个修订版本之间的 Google Markdown 或文本导出内容的统一差异。read_document 可读取整个旧版 revision。
edit_table	insert_table（使用数据网格）、set_cells（逐单元格应用最小差异）、insert_rows、delete_rows、insert_columns、delete_columns、merge_cells、unmerge_cells、style_cells、style_columns（固定列宽或均分列宽）、style_rows（最小行高、分页行为）、pin_header_rows。与文本编辑使用相同的模式和保护机制。
insert_object	在指定位置插入来自公开 URL 的行内图片、人员标签、富链接标签或日期标签；就地替换图片来源；或删除对象，包括没有文本范围覆盖的浮动图片。
layout_document	page（页面大小、页边距、背景、横向、页码、首页／偶数页页眉、无分页模式）、section（对单个分节设置相同选项，另加 1–3 栏）、section_break，以及 named_style（为整个标签页重新定义 NORMAL_TEXT、TITLE、SUBTITLE 或 HEADING_1 … HEADING_6）。
manage_tabs	添加（含内容）、重命名、移动或嵌套标签页。始终直接操作：API 无法建议更改标签页。
write_markdown_file	将工作副本写回其 Markdown 文件，只携带副本中的变更；若文件自此之后发生过变更，则会拒绝写入，除非启用强制；尚未保存的 Docs 编辑器变更绝不会被覆盖；支持 dry_run。
另外两个工具仅在 GDOCS_ENABLE_DESTRUCTIVE=true 时注册：
delete_comment（删除一个讨论串或其中一条回复）和 delete_tab（删除一个标签页及其内容和子标签页）。两者都带有破坏性注解，每次调用都必须在 confirm_comment_id 或 confirm_tab 中再次指定目标。
delete_comment 还需要 text_start，即要删除的文本开头，须与 list_comments 显示的一致，这样客户端的提示词才能显示要删除哪条评论；服务会读取评论，如果内容不同则会拒绝并返回 [stale]。

文档可通过 ID、任何 docs.google.com URL，或 Markdown 文件的 drive.google.com/file/d/… URL 来标识。

资源

将上下文作为 MCP 资源附加的客户端，无需调用工具即可读取文档。每个资源都是 Markdown，不含句柄、建议或评论；读取工具用于有范围和预算限制的读取。

• gdocs://<id> — 所有标签页的正文，最多截取 400000 个字符，并注明可从何处继续使用 read_document 读取。
• gdocs://<id>/outline — get_outline 返回的标题树。
• gdocs://<id>/tabs/<tab> — 一个标签页的正文；tab 可以是 ID、标题或序号。

如何指定编辑位置

模型不会看到索引编号。目标可以是从读取内容中精确引用的文本（弯引号、短横线和空格会标准化；文本必须只出现一次，否则用 occurrence / within 消除歧义）、通过稳定的 heading_id 指定的整个章节、通过句柄指定的块（如 p12，仅对其来源修订版本有效，使用时会重新检查）、表格单元格，或命名范围。命名范围是唯一能在编辑后继续有效的锚点：Google 会随其覆盖的文本移动该范围，因此现在调用 create_named_range，之后调用中的 target: {named_range: …} 就能定位到同一段内容。新内容以 Markdown 编写。replace 会以新旧文本之间的最小差异进行替换，因此未改动的词语会保留其格式和锚定的评论。

表格通过句柄命名（tbl1），单元格表示为 r2c3；如果表格需要数据网格，会先插入空表格，再在其存在后通过第二个批次填充。表格操作按顺序读取：一旦某项操作更改了网格，该表格后续的操作就会在单独的批次中执行，因此其行、列和单元格编号表示届时的网格。旧修订版本通过 Google 的导出功能读取并比较，因此没有句柄。

安全

• 读取工具标注为只读。写入工具接受由使用者选择的 mode：suggest（跟踪更改）、direct 或 comment（将提议作为评论发布，不编辑任何内容）。每次写入都会根据规划时所依据的修订版本进行保护；如果有并发编辑，会重新规划一次，然后拒绝操作。

• 直接编辑绝不会删除包含评论锚点、待处理建议、图片或脚注的范围，除非明确强制执行。

• 删除评论或标签页的破坏性工具仅在 GDOCS_ENABLE_DESTRUCTIVE=true 时注册。GDOCS_READ_ONLY=true 仅注册读取工具，并请求只读权限范围。

• 每次调用都由你的 MCP 客户端批准；服务不会询问你。 claude.ai 和 Codex 会提示确认这两种删除操作，并将其标记为破坏性操作。VS Code 会提示确认每个非只读工具：所有写入操作，以及会写入本地文件的 export_document。在 Claude Code 中，在设置的 permissions.ask 下逐一列出你要批准的调用，并用你为服务指定的名称替换 google-docs。例如，删除操作、审查他人的建议，以及将 Markdown 文件写回：

  {
    "permissions": {
      "ask": [
        "mcp__google-docs__delete_comment", "mcp__google-docs__delete_tab",
        "mcp__google-docs__review_suggestion", "mcp__google-docs__write_markdown_file"
      ]
    }
  }
  

  GDOCS_REQUIRE_PROMPT 已移除：将其设为任何非 false 的值，服务都不会启动。对于无人监管运行的客户端，请勿启用 GDOCS_ENABLE_DESTRUCTIVE。

• 服务仅与 Google 通信（googleapis.com，以及 Google API 返回的修订版本导出链接所用的 docs.google.com）。不进行遥测。日志（stderr）绝不包含文档文本。

• 刷新令牌存储在操作系统密钥环中；logout 会撤销并删除令牌。

工作原理

MCP client ──stdio──► google-docs-mcp
                       ├── tools     one handler per tool; shapes the reply
                       ├── service   orchestration and scope resolution
                       ├── plan      write planning and all the index math
                       ├── doc       model, handles, sections
                       ├── render    markdown, text, outline
                       ├── gapi      raw REST client for Docs and Drive
                       └── auth      refresh token → access token

索引计算不会离开服务端：模型通过精确文本、heading_id 或句柄定位内容，internal/plan 会将其转换为 Docs API 所需的 UTF-16 偏移量。internal/gdocs 中的线缆类型由本项目自行定义，并通过一道门禁与 Google 发布的发现文档保持一致，而不是使用生成的客户端。

获取帮助

google-docs-mcp doctor 会检查凭据、权限范围和 API 连通性，并指出缺少的内容；首次运行时遇到的大多数问题，都是因为从未启用 API，或是你不在授权同意屏幕上。如果这仍无法解释问题，请提交 issue——错误报告表单会要求提供 doctor 输出和版本号。

切勿在 issue 中粘贴文档 ID 或 URL、文档内容、client_secret.json 或令牌；请改为描述文档的结构。安全问题请通过 SECURITY.md 私下报告。

版本管理

从 v1.0.0 起，遵循预期的语义化版本规则：移除或重命名工具、将参数改为必填，或更改工具返回内容，都会导致主版本号递增。新增工具和新增可选参数属于次版本更新。CI 中的架构差异检查负责执行此规则，并在每个拉取请求中运行——工具接口的变更必须由差异检查明确指出。

唯一的例外是工具文本输出的确切措辞，这一点在此明确说明，避免意外：文本输出是为模型阅读而编写的，如果模型对其理解不佳，就会重新措辞。工具返回的 structuredContent 受此规则约束；围绕它的句子则不受约束。

每个版本的说明对应 CHANGELOG.md 中的同名章节；任何需要你采取行动的变更——新增权限范围、重新登录，或更改客户端配置中的命令——都会在其中标记为 Breaking:。

开发

make build     # the binary
make test      # race detector, coverage floor
make check     # everything CI runs

make check 是完成标准：格式检查、在每个构建标签下运行 go vet、golangci-lint、带有每个包覆盖率下限的竞态测试、govulncheck、许可证检查、密钥扫描、API 覆盖率门禁，以及 API 字段门禁（若 Google API 方法或字段没有审核结论，则检查会失败）；此外还包括针对已发布工具接口的架构差异检查、stdio 冒烟测试，以及新鲜度门禁（若本 README、文档或更新日志与代码不一致，则检查会失败）。

测试夹具均为合成数据。切勿添加真实文档中的内容、ID 或 URL。make bench 用于测量大型文档路径的性能；go test -tags=evals ./internal/evals 会使用你自己的账号运行 Agent 评测（参见包注释）。

文档

• docs/architecture.md — 设计、请求流程、支撑每项约定的证据日志，以及贡献者不应撤销的决策。
• docs/configuration.md — 所有环境变量和标志。
• docs/security.md — 威胁模型：哪些内容会进入日志、doctor 会打印什么、驱动会写入什么。每项声明都有测试支持。

参与贡献

问题和错误请提交到 issues；欢迎提交拉取请求。CONTRIBUTING.md 介绍了分支和评审流程，必须通过 make check。

安全

SECURITY.md 说明了安全问题的范围，以及如何私下报告漏洞。请勿为此公开提交 issue。

行为准则

CODE_OF_CONDUCT.md — Contributor Covenant 3.0。

许可证

Apache-2.0 — 详见 LICENSE。