todox

todox

为开发者及其 Agent 提供工作记忆。 它不是清单，而是一份日志，让你下次会话能真正接续上次的进度。

问题跟踪器是为人与人协作而编写的。todox 则是为 Agent 与 Agent 协作而编写的， 同时也让人能在一旁查看。每项任务都会记录背后的决策、失败的做法、尚未解决的问题， 以及上一轮会话留下的备注。

新的 Agent 会调用 get_context，阅读内容后从上一个 Agent 停下的地方继续，而不会再次撞上别人已经遇到过的障碍。简报设有行数和字节数上限， 不会无限增长；它还会说明哪些内容因上限而未纳入，而不是默默删减。内容绝不会被截断到半句话： 每条记录都会附上名称、日期和首行；body 为 null 表示预算已用尽，而不是记录为空。

工作原理

Agent 负责写入，你在一旁查看。每个代码仓库对应一份日志，无论最后由哪台机器或哪个 Agent 操作：

项目	单个项目

日志中记录什么

类型	含义
decision	你做出的选择，以及其他方案为何落选
dead_end	行不通的做法——价值最高的条目，因为它能避免重蹈覆辙
question	只有人类才能回答的问题
handoff	会话结束时的状态，写给接手的人看
note	其他所有内容

将日志视为产品，会带来两项优势：

• 过时的上下文会被标记，绝不伪装成新内容。 链接文件由能看到文件的一方——Agent——计算哈希，服务端则保存哈希并进行比较。如果代码发生变化，get_context 会说明备注可能已不再准确。 在 Agent 实际检查之前，备注会标记为“从未检查”，而不会声称内容仍然有效：会误导人的上下文比没有上下文更糟糕，这也包括谎称我们有多确定。
• 报告来自日志，而非提交记录。 每次状态变化都会成为一个事件，因此“我今天完成了什么、花了多久、由哪个模型完成”是查询结果，而非考古工作。任务状态设为 doing 后就被搁置，统计时算作设置该状态的那天，而非之后的几周——报告也会说明遗漏了多少内容，而不是将其混进摘要。
• 可以查询某个文件的相关信息。 这些携带哈希的链接也可以从另一端读取：get_file_context 接收路径，并返回涉及该文件的任务、相关失败尝试，以及附加在文件上的长期备注。路径会转换为相对于代码仓库的形式，因此在一台机器上创建的链接，也能在另一台机器上找到。

为什么不使用 Agent 已有的记忆？

Claude Code 现在会自己写笔记（自动记忆自 2026 年 2 月起默认启用），Cursor 和 Codex 也有各自的记忆。尽管使用：它们很擅长记住你偏好 pnpm。它们的文档用自己的话说明，这些记忆按仓库、按机器（“仅限本机……不会在不同机器间共享”）和按工具划分，并且不与任何人共享（“只有你自己可见”）。todox 用于处理这些界限之外的内容：

• 两台机器，一份日志。 仓库通过远程地址识别，因此在笔记本上留下的记录也能在台式机上读取。
• 每个 Agent，一份日志。 Claude Code、Codex、Cursor 和 VS Code 都支持 MCP；无论下一个使用的是哪个 Agent，它都能读取上一个 Agent 留下的交接记录。
• 也包括团队成员。 项目可以共享，日志会记录每条内容的作者和使用的模型。
• 文件笔记不具备的结构。 可以开启和关闭的任务、单独归类的死胡同、从日志读取的报告、明确标记为过时的笔记，以及会报告因容量限制而未纳入内容的简报。

与其他记忆服务对比

根据各项目自身 README 中的说明进行比较（阅读日期：2026-10-16）。如果 README 没有说明某项内容，表格会如实注明，而不作推测。

	todox	MCP memory server	Basic Memory	Mem0
存储内容	任务，每项任务都有决策、死胡同、问题和交接记录；常驻笔记	知识图谱：实体、关系、观察记录	Markdown 笔记，使用本地 SQLite 索引	大模型从对话中提取的事实
存储位置	Postgres，可托管或使用你自己的实例	本地 JSONL 文件	磁盘上的文件；付费云端选项可同步这些文件	可自托管的服务或托管平台
两台机器	一份日志，仓库通过其 git 远程地址识别	未说明；该文件不适合存放在网络文件系统中	手动同步（Git、Syncthing）或使用云端选项	通过服务或平台
支持结构化工作	是：任务可以开启和关闭，死胡同有独立类型	未说明	带分类的自由形式观察记录；未说明任务或死胡同类型	未说明
能识别代码变更	是：Agent 会对关联文件进行哈希计算，文件变更时会标记出来	未说明	未说明	未说明
需要大模型 API 密钥	否	未说明	未说明	是；默认使用 OpenAI

它们解决的是不同的问题。知识图谱或笔记库适合存放关于某个人或某个领域的事实；todox 用于记录仓库中的工作状态，以及避免重复犯下在那里已经失败过的错误。

试用

todox.dev —— 任何人都可以注册。这是一个小型个人部署，不承诺正常运行时间。如果这份日志对你很重要，请自行托管。

运行自己的实例

pnpm install
cp .env.example .env.local     # any Postgres 15+; see below for a container
pnpm db:migrate                # idempotent
pnpm seed                      # optional demo account: demo / todox-demo
pnpm dev

连接 Agent

todox 是一个远程 MCP 服务。无需安装任何内容，也无需克隆仓库：让任意 MCP 客户端使用 Agent 令牌连接到该 URL 即可。

在 Account 页面创建令牌后，页面会提供一段文本，可直接粘贴到你使用的 Agent 中，还会提供四种常见 Agent 的配置片段。 格式始终相同——一个 URL，一个标头：

Claude Code 有更快捷的方式。 插件包含服务、作为技能的会话协议，以及一条会话开始时的提醒；它只会询问一次令牌，并将其保存在你的 Claude Code 设置中：

claude plugin marketplace add beydemirfurkan/todox
claude plugin install todox@todox

以下内容仍然适用于它——插件也是同样的四行，只是通过安装而非粘贴来配置。请参阅 plugin/README.md，了解它的功能和不包含的功能。

# Claude Code. --scope user, because the default is this directory only.
claude mcp add --scope user --transport http todox https://www.todox.dev/api/mcp \
  --header "Authorization: Bearer todox_…"

// OpenCode v1 — ~/.config/opencode/opencode.json.
// MCP key is `mcp` (server name is a direct key under it), NOT `mcpServers`.
// `type` is `"remote"`, NOT `"http"` — the Claude/Cursor/VS Code value is
// silently ignored on OpenCode.
{
  "mcp": {
    "todox": {
      "type": "remote",
      "url": "https://www.todox.dev/api/mcp",
      "headers": { "Authorization": "Bearer todox_…" }
    }
  }
}

// OpenCode v2 — same key, server now nested under `mcp.servers`.
{
  "mcp": {
    "servers": {
      "todox": {
        "type": "remote",
        "url": "https://www.todox.dev/api/mcp",
        "headers": { "Authorization": "Bearer todox_…" }
      }
    }
  }
}

# Codex — ~/.codex/config.toml
[mcp_servers.todox]
url = "https://www.todox.dev/api/mcp"
http_headers = { Authorization = "Bearer todox_…" }

// Cursor — ~/.cursor/mcp.json, the one in your home directory.
{
  "mcpServers": {
    "todox": {
      "type": "http",
      "url": "https://www.todox.dev/api/mcp",
      "headers": { "Authorization": "Bearer todox_…" }
    }
  }
}

// VS Code — the user-level mcp.json ("MCP: Open User Configuration").
// The root key is "servers", NOT "mcpServers". This is the one client
// that differs, and getting it wrong is silent.
{
  "servers": {
    "todox": {
      "type": "http",
      "url": "https://www.todox.dev/api/mcp",
      "headers": { "Authorization": "Bearer todox_…" }
    }
  }
}

MCP 配置键和 type 值因 Agent 而异，组合错误时会被静默忽略——没有错误，也没有警告，工具就是不会显示：

Agent	键	type
Claude Code	mcpServers.NAME	"http"
OpenCode v1	mcp.NAME	"remote"
OpenCode v2	mcp.servers.NAME	"remote"
Cursor	mcpServers.NAME	"http"
VS Code (Copilot Chat)	servers.NAME	"http"
Codex	TOML [mcp_servers.NAME]	不适用

这些文件的位置因平台而异，而 VS Code 的文件位置最容易和 Linux 用户习惯的位置不同：

Agent	macOS	Linux	Windows
Claude Code	~/.claude.json	same	same
Cursor	~/.cursor/mcp.json	same	same
Codex	~/.codex/config.toml	same	same
OpenCode	~/.config/opencode/opencode.json	same	same
VS Code	~/Library/Application Support/Code/User/mcp.json	~/.config/Code/User/mcp.json	%APPDATA%\Code\User\mcp.json

请全局安装，不要按项目安装。 这些工具默认使用你当前所在的目录——claude mcp add 不指定作用域、.cursor/mcp.json、.vscode/mcp.json——而记忆只存在于一个仓库中，恰恰背离了初衷。这样也会悄无声息地失效：换到下一个项目时，工具就不在那里了，因此 Agent 也不会提及它们。

请明确写出 "type": "http"。如果客户端找到 url 却没有 type，通常会假定这是一个本地命令，然后报出含糊不清的错误。

接下来，让你的 Agent 使用它

连接上并不等于实际使用，两者之间的差距比看起来更大。 MCP 服务的 instructions 只是背景资料；skill 或 CLAUDE.md 规则才是指令。当两者冲突时，MCP 服务会落败——我们在一个全新的项目中进行了测量，todox 始终保持连接，却一次也没有被调用。

因此，请在 Agent 实际遵循的记忆文件中加入以下四行：

todox MCP is installed here — persistent memory across projects.

- Call `get_context` before starting non-trivial work (cwd = your working
  directory). It registers a new repo by itself.
- `create_task` for anything that will not finish this session.
- Before stopping, `session_status` lists what you touched; leave a
  `log_entry(kind:'handoff')` on each, and `dead_end` for approaches that failed.
- Always pass your own model id.

也可以让安装程序代劳：

pnpm install:mcp claude-code --write-memory

除非你主动要求，否则不会进行写入，因为那个文件属于你，而不是我们；此操作也是幂等的——内容会用 HTML 注释括起来，第二次运行时会替换原有内容，而不是留下两套指令，让旧指令占上风。添加 --dry-run 可先查看准确内容。

如果工具完全没有显示出来，通常是上面两张表中提到的某个问题导致的静默失败。你可以运行一个命令，让它按照各客户端读取文件的方式进行检查，并指出问题：

npx https://github.com/beydemirfurkan/todox/releases/latest/download/todox-mcp.tgz doctor

对于每个客户端，它都会列出对应条目、其 type、根键、位于客户端不会读取的位置的残留配置、记忆文件中是否包含这个使用习惯，以及服务是否会响应找到的令牌（输出中会对令牌进行遮蔽）。它还会准确指出当前检出目录自身配置中的 todox 条目。不会修改任何内容；详情请见 docs/mcp.md。

如果你跳过这一步，而账户随后连续数天保持连接却没有调用任何工具，那么服务会在下一次会话的指令顶部指出这一点——“已连接 N 天，且尚未调用工具”——并向 Agent 提供这四行内容和客户端记忆文件的路径，要求它追加这些内容并告知你已完成。此时间根据 tool_usage 计算，因此只有在情况属实时才会提示，并在工具一经调用后立即停止。这能让客户端发生变化或记忆文件从未写入的账户恢复正常，而无需任何人主动提出。

用户级文件，而非项目级文件。 这和上面的配置是同一个陷阱，只是相差一个目录：

Agent	适用于所有项目的文件
Claude Code	~/.claude/CLAUDE.md
Codex	~/.codex/AGENTS.md
Cursor	~/.cursor/rules/todox.md
VS Code	~/.copilot/instructions/todox.md
OpenCode	~/.config/opencode/AGENTS.md

代码库自带的 AGENTS.md，以及编辑器同样会读取的项目级规则文件，只在该检出目录内生效。把跨项目记忆安装到某个项目中，正是本节旨在避免的问题。

更完整的版本，以 skill 的形式提供。 这四行是使用习惯；完整的会话协议——即服务在 initialize 时发送的相同文本——也可以放在客户端的用户级 skills 目录中。到了适用场景时，这些客户端都会根据描述加载 SKILL.md，否则不会消耗任何上下文：

pnpm install:mcp claude-code --write-skill

Agent	加载的 skill 文件
Claude Code	~/.claude/skills/todox/SKILL.md
Codex	~/.agents/skills/todox/SKILL.md
Cursor	~/.cursor/skills/todox/SKILL.md
VS Code	~/.copilot/skills/todox/SKILL.md
OpenCode	~/.config/opencode/skills/todox/SKILL.md

该文件完全属于 todox——它独占一个目录，里面没有任何你的内容——因此升级后再次运行会替换它。文件由与服务指令相同的文本生成，而非重复编写，这样才能确保两者不会互相矛盾。

令牌不会写入该文件，而是保存在你的 MCP 配置中。这是使用习惯，不是凭据。

可选：本地模式

托管服务没有文件系统，但你的 Agent 有，这就够了： 它关联文件时会发送哈希（这会被视为一次检查，因此链接会立即显示为最新）， 之后会用找到的内容调用 report_file_hashes，所以通过 HTTP 也能像在其他地方一样判断是否过时。十六进制字母大小写均可接受，因此 PowerShell 的 (Get-FileHash f).Hash 可以直接使用。

stdio 服务会自行处理这部分，而不是询问。若你不想让 Agent 在这上面分心，或希望即使 Agent 忘了也能进行哈希计算，那么值得运行它。无需克隆：

TODOX_TOKEN=todox_… TODOX_URL=https://www.todox.dev \
  npx https://github.com/beydemirfurkan/todox/releases/latest/download/todox-mcp.tgz

也可以使用 MCP 配置，这是 Agent 需要的形式：

{
  "mcpServers": {
    "todox": {
      "command": "npx",
      "args": [
        "-y",
        "https://github.com/beydemirfurkan/todox/releases/latest/download/todox-mcp.tgz"
      ],
      "env": { "TODOX_TOKEN": "todox_…", "TODOX_URL": "https://www.todox.dev" }
    }
  }
}

没有 npm 包，这是经过考虑的决定，并非待办事项。 发布或安装 GitHub Release 无需账户或令牌，因此 tarball 就是完整的发行包，npx 可直接使用其 URL。上面的 URL 始终指向最新版本；每个 Release 也都附带 todox-mcp-<version>.tgz，方便你固定版本并自行决定何时升级。

它只包含 stdio 服务实际加载的内容——没有 Next、没有 React、没有 Postgres 驱动，因为它通过 HTTP 与 API 通信，不会打开数据库。pnpm pack:mcp 会构建该包，并在任何服务端内容再次进入工具接口时使构建失败。

从克隆的仓库运行时，pnpm -C /path/to/todox mcp 仍然有效；修改工具本身时应使用此命令。

工具

工具	功能
get_context	请先调用。 常驻规则、项目决策和注意事项、每项未完成任务及其决策、走不通的路径、问题、文件和上次交接内容，以及过时文件警告。可通过 slug、名称或项目内的任意路径解析项目。返回记录数和字节数均有限制，但绝不截断：每条记录都会保留其 id、类型、日期和首行；body 为 null 表示预算已用完，可通过 get_task 读取。超过 14 天未更新的未完成任务会逐项列在 idle_tasks 中，包含标题、状态、闲置天数和上次交接的开头，且不占用任何预算。传入 focus——一句说明本次会话目的的话——两个预算都会优先用于回答该目的的记录，而不是最新记录，因此可以设置得更小。
create_task	记录工作。传入 cwd 或明确指定 project；工具架构要求调用前必须提供其中一个。注册新项目还需要 repo_root 或 repo_url。回执会返回任务路径和正文长度，但不会回显正文。
update_task	更新状态、标题、正文和优先级。时长数据在任务转为 doing/done 时生成。
log_entry	追加五种类型之一的记录。answers_entry_id 用于关闭 question——只有这一操作能关闭它。
delete_entry	用于删除写入时就有误的记录。被后续工作取代的记录属于历史，而非错误——应追加新记录。
activity_report	查看今天、本周或任意时间段的数据：时长、模型、重要性、决策、走不通的路径和未解决问题。format:"markdown" 的输出适合粘贴到状态更新中。
link_files	将文件路径及其哈希关联到任务或上下文备注——包括工作涉及的文件，以及工作遵循的计划，无论计划存放在哪里：仓库外的路径也会像其他路径一样计算哈希；URL（例如 claude.ai 上的 artifact）会按原样保存，不会计算哈希。同一文件可重复调用。
report_file_hashes	仅托管版：查看关联文件当前在磁盘上的情况。本地进程会自行执行此操作。
accept_file_change · unlink_file	阅读更改后清除过时警告，或移除已失去意义的关联。只有这两种操作能清除警告——服务端无法查看文件。
add_context	添加生命周期长于任务的知识；省略项目即可将其设为整个账户通用。
get_context_note	完整读取一条备注，适用于正文因简报预算限制而未完整显示，或需要查看搜索摘要之外的内容时。预算未能涵盖的记录可通过 get_task 读取。
get_file_context	查看关于某个文件的已知信息：涉及该文件的任务及其走不通的路径，以及关联到该文件的备注；每项都包含其关联信息（id、哈希、状态）。没有关联时返回 linked:false。支持绝对路径或相对仓库的路径；两种方式都能找到在另一台机器上建立的关联。
session_status	结束前请调用。 列出过去 12 小时内你在此项目中更改或处理过的任务（任何状态），并标明自上次操作以来是否写过交接内容；此外，还会列出已处于 doing 状态 7 天以上且没有日志的任务。每项包含 id、标题、日期和一个布尔值；hint 会说明各列表仍需完成什么。收尾规则要求为每项处理过的任务写交接内容；此列表正是系统假定 Agent 会记得的内容。
update_context · delete_context	更正后来发现有误的备注。只能追加而无法更正的日志终将不再值得阅读。
search	在你的所有项目中搜索，并按相关性排序。用文字提问；加引号的短语必须匹配。支持英语和土耳其语词干，也能匹配标识符中间部分。只被其中一种语言视为噪声的词会被忽略，因此提问不会匹配每条包含单词 "a" 的记录。使用 kinds 将范围缩小到走不通的路径或决策；使用 project 限定搜索范围。请使用日志所用的语言提问——此工具会提取词干，但不会翻译；如果句子搜索不到结果，请改用有辨识度的标识符重试（至少 3 个字符；更短的标识符只会作为完整单词匹配）。
get_task	查看一项任务及其日志和关联文件。
list_tasks · list_projects	当 get_context 提供的信息超出所需范围时，使用简单列表。项目按最近活动时间从新到旧排列，并包含 activity_at。
create_project · update_project	很少需要：使用带 cwd 的 create_task 会注册项目。已注册的路径或远程地址会返回对应项目，而不会创建重复项目。建议添加摘要。
delete_project	用于撤销因 cwd 拼写错误而创建的项目。此操作会删除项目及其所有内容；confirm 必须是 slug。
merge_projects	用于合并因同一仓库被重复注册而产生的项目。此操作会将任务、备注和路径移入保留的项目；confirm 必须是要合并移除的项目的 slug。
每个写入工具都会接收一个 model，服务器指令会告诉 Agent 始终传入它。这样按模型划分的数据才是实际数据，而非猜测。

提示词

这里有三个提示词，因为它们分别适用于三个时刻。它们会显示在客户端自己的菜单中，因此你不用阅读任何内容，就能看到服务器的行为：

提示词	适用时机
start_session	规划前——阅读之前的会话确立了什么
wrap_up	结束前——留下交接信息，尤其是走不通的路
standup	有人询问完成了什么时

部署

一个容器，旁边配一个 Postgres。根目录下的 docker-compose.yml 已经将它们组合在一起——数据库完全不发布端口，只能通过 compose 网络访问：

cp .env.example .env       # set POSTGRES_PASSWORD and TODOX_PUBLIC_URL
docker compose up -d --build
docker compose exec app pnpm db:migrate

迁移特意单独执行；请参阅本节末尾的说明。todox.dev 本身也在同一台主机上运行这两个容器。

变量	用途
DATABASE_URL	Postgres。数据库与应用位于同一网络时，这里填写它的服务名称，无需证书或公开端口。
DATABASE_POOL_MAX	可选，默认为 10。此进程可持有的连接数。只有在确认服务器自身的 max_connections 后再调高，因为所有副本共用该限制。
TODOX_PUBLIC_URL	验证链接、重置链接和 Agent 设置代码段都由此生成——如果配置错误，用户和他们的 Agent 就会访问错误的主机。
SMTP_HOST · SMTP_USER · SMTP_PASS · MAIL_FROM (· SMTP_PORT)	可选，但前四项必须一起配置。未配置时，邮件会输出到服务器日志，而不会发送。端口默认为 587（STARTTLS）。MAIL_FROM 可填写什么取决于服务提供商：邮箱服务提供商通常要求使用已通过身份验证的地址，而 API 密钥服务提供商则接受该服务已验证域名下的任意地址。如果达到发送限额，邮件会被丢弃，失败信息只会出现在日志中。

架构变更时运行 pnpm db:migrate。它有意不在启动时运行：滚动部署期间多个实例同时执行 DDL 来争抢锁，是发现锁竞争的糟糕方式；而架构具备幂等性，正是为了能在部署后决定何时执行迁移，而非部署期间。请在主机上运行：

docker exec <container> pnpm db:migrate

这也是镜像保留开发依赖、而不使用 Next 的 standalone 输出的原因——精简依赖会移除 tsx 和 scripts/ 下的所有内容；而无法从互联网访问的数据库，只能从已经位于网络内的环境执行迁移。

确认部署确实生效

合并不等于部署，两者之间的间隔悄无声息：没有报错，网站依然运行，唯一的迹象是你看着变绿的修复并不是用户正在使用的版本。2026-09-05，这个实例运行的代码比最新代码落后两天和 56 次提交；让问题显现出来的不是任何报告，而是有人去查看了。

镜像标签就是 git sha，且每次部署都会更改容器名称，因此只需一行命令就能确认：

docker inspect <container> --format '{{.Config.Image}}'

将结果与 git rev-parse origin/main 对比。如果两者不同，你正在查看的代码就不是当前运行的代码。

值得配置自动部署，也值得在配置后检查。通过 webhook 拉取代码的平台，即使开关已开启，也可能始终不触发，因为开关和 webhook 分别位于两个地方的两个设置中：这个实例的自动部署已启用数周，但仓库根本没有 webhook，因此从未有人通知平台检查更新。配置 webhook 后，请从发送端确认——查看投递日志，而不是看开关；因为指向错误路径的 webhook 也会正常响应，却什么都不做。

随身携带数据

账户页面有一个 下载我的数据 按钮，而 /api/export 会向持有令牌的客户端返回同一个文件，因此 Agent 可以写入备份，而不必让结果经过模型。备份包含你拥有的所有项目及其任务、日志、上下文笔记和文件哈希，不包含任何其他人的信息：没有凭据、协作者、共享令牌，也没有与你共享的项目，因为那些项目属于创建者。

将数据加载到你运行的实例中：

pnpm db:import ./todox-export-2026-08-18.json your-username

只会追加，绝不破坏：不会删除或覆盖任何内容；如果项目的 slug 已被占用，就会使用下一个可用的 slug。任务事件也会一并迁移，因此恢复副本上的报告所显示的耗时，与原始项目上的一致。

安全性

密码使用 scrypt；会话、Agent 令牌和电子邮件链接只以哈希形式存储。所有权检查集中在一个模块中；如果某行属于其他人，会返回 404 而非 403，以防探测 ID。速率限制存储在数据库中，因此在多个实例间也能生效。

详情以及坦诚列出的未覆盖事项，见 SECURITY.md。

已知不足

• 只有在数据库支持的情况下，搜索的子串匹配部分才会建立索引。两部分分别查询后再合并，因此任一部分都能使用索引——在 11 万行数据上测得，仅全文搜索部分的查询时间就从 5.7 秒降至 0.16 秒。用于查找全文搜索无法识别的标识符的 ILIKE 部分需要 pg_trgm；pnpm db:migrate 会在当前角色有权限时创建扩展和五个索引，并报告结果。如果无法创建——例如使用不带 contrib 的 Postgres，或拒绝安装扩展的托管服务——该部分就会继续执行顺序扫描，pnpm smoke:search 会为它打印 SKIP，而不会失败。docker-compose.yml 中的 postgres:18 镜像包含该扩展。
• 过时状态按文件哈希判断；按符号判断才是更准确的做法。在托管环境中，这取决于 Agent 是否实际发送哈希——说明中虽有要求，但无法强制做到。
• 测试覆盖率约为 39%，但覆盖范围比数字更重要：Agent 接口、身份验证边界以及负责回答“这是否属于你”的存储库都有覆盖，而 UI 的大部分没有。
• 观察信息能看到 git 可提供的内容，以及会话设为 doing 的任务，因此可以回答“发生了什么变化”和“改动涉及什么”，但永远无法回答“为什么”。承载推理过程的部分是对话记录，而能提供对话记录的 Hook API 只属于一个客户端。
• 简报的字节预算涵盖日志正文、笔记正文和任务正文。仍有一个维度只受行数限制：所携带条目的 标题 和任务，共五十个任务的量。它远小于预算调整后节省的内容——一个项目的日志数据就从 143 KB 降到了约 55 KB——但它并没有字节数上限；pnpm bench:memory 会打印这一数值，让后来者不必自行发现。
• 观察信息仅由本地进程采集。 监视 git 必须在保存工作副本的机器上运行，而托管端点不具备此能力——因此，以这种方式连接时，每份简报中的 observations 部分都会为空，也没有任何地方会填充该部分。本 README 中的试用方式采用托管版本，因此大多数人都会遇到这种情况。负责采集观察信息的传输方式是 npx todox-mcp。其他功能在两种方式下都完全相同。
• 不支持双重身份验证、按会话撤销或审计日志。
• 共享链接不公开列出，但没有访问控制。
• 除了用 / 搜索外，不支持键盘导航。

发布版本

git tag v0.1.4 && git push origin v0.1.4

流程就是这样。工作流会将标签与 package.json 中的版本核对，运行检查，构建 stdio 软件包，并将其附加到 GitHub Release——无需账号或凭据，因此从第一个标签开始，npx <that tarball url> 就能使用。

会上传两个名称：todox-mcp-<version>.tgz，以及内容相同的 todox-mcp.tgz，这样 /releases/latest/download/todox-mcp.tgz 就是一个值得写入配置一次的地址。我们有意不向 npm 发布任何内容——请参阅上文的本地模式部分。

server.json 会将 MCP 注册表条目固定到相同版本，server-json.test.ts 也会确保这一点，因此标签、软件包和注册表要么保持同步，要么发布就会停止。

贡献

了解代码库实际遵循的规则，以及如何运行检查： CONTRIBUTING.md。

MIT——请参阅 LICENSE。