把 Claude Code 当主力工具的这些日子，我最怕的一件事就是换电脑。公司台式机、家里 MacBook、出差用的 Windows 笔记本，四台机器来回切，经常是这台机器上调好的权限规则、写了一半的全局记忆、攒下来的自定义 skills，换到另一台机器上打开终端——全没了。后来我把“换台电脑配置全丢”这个痛点当成一个正经项目来做，折腾出一套四机同步方案，彻底解决了这个问题。
这篇内容就是完整复盘：Claude Code 的配置到底存在哪里、哪些该同步哪些不能碰、为什么我放弃云盘选了 Git + 符号链接，以及整套方案的从零搭建过程。适合所有在多台电脑上高强度使用 Claude Code 的人，也适合刚接触不久、想一开始就把配置管理好的新手。
1. 换台电脑就失忆：Claude Code 的配置到底存哪儿了
1.1 “全没了”不是玄学：本地文件才是它的家
很多人换电脑时会下意识地以为“只要登录同一个账号，配置应该自动跟着走”。实际用下来你会发现，Claude Code 的客户端是典型的本地优先架构，它把大量与个人使用习惯相关的配置存在当前用户主目录下的隐藏目录.claude里，并不会因为你登录了同一个账号就自动同步到另一台机器。
在 macOS 和 Linux 上这个目录是~/.claude，在 Windows 上是%USERPROFILE%\.claude。你定义的权限策略、默认模型、环境变量、全局记忆 CLAUDE.md、自定义 skills，以及一大堆会话历史，全都堆在这个目录里。服务器端只负责对话上下文和账号订阅状态，用户本地的配置和记忆，本质上还是“跟机器走”。
这就解释了一个现象：你换台电脑，claude命令还能用，账号也正常，但之前调好的规则、写好的记忆、装的 skills 全不见了。因为那些东西从来就没有离开过原来那台机器的磁盘。所以要解决“换台电脑全没了”，得先把配置本身当成可以迁移、可以版本管理的东西来对待。
1.2 一次目录体检：哪些该同步，哪些必须隔离
直接对整个.claude目录做同步是最省事的做法，但也是最容易踩坑的做法。目录里既有你精心维护的配置，也有不能外泄的凭据，还有大量没有价值的缓存。动手之前，先花两分钟认识一下这个目录的典型结构：
~/.claude/ ├── settings.json # 用户级设置：权限、模型、环境变量 ├── CLAUDE.md # 全局记忆，每次对话自动加载 ├── .credentials.json # 登录凭据和 token，敏感 ├── projects/ # 按项目路径编码的会话历史 ├── skills/ # 自定义技能目录 ├── todos/ # 待办数据（如果开启了相关功能） ├── statsig/ # 遥测缓存，可忽略 └── ...我的分类原则很明确：
- 一定要同步的：
settings.json、CLAUDE.md、skills/，这是你在多台机器上保持一致体验的核心。 - 必须隔离的：
.credentials.json以及任何包含密钥、token 的文件。这类文件进 Git 仓库等于把家门钥匙挂在门口，哪怕私有仓库也不能掉以轻心。 - 建议不同步的：
projects/会话历史，体积增长快，而且跨平台路径编码对不上，后面我会详细说。 - 纯垃圾：
statsig/、各种临时文件，直接忽略。
把边界划清楚，同步方案才有实现的可能。如果眉毛胡子一把抓全塞进仓库，过不了几天就会因为凭据泄露、仓库膨胀、冲突不断而放弃。
2. 同步方案选型：为什么最终选了 Git + 符号链接
2.1 我试过的几种方案：云盘、dotfiles 工具、Git 脚本
最初我图省事，直接把.claude文件夹丢进云盘同步盘里，想在四台机器之间自动同步。实测下来问题很多：第一，.credentials.json裸奔在云盘上，等于把自己的账户钥匙放在第三方同步链路里，一旦云盘账号出问题或被同步到其他设备，风险完全不可控；第二，多台机器同时改动配置文件时，云盘会生成一堆“xxx（冲突的副本）”文件，Claude Code 读的是原路径的 JSON，冲突文件一旦把原文件覆盖掉，启动直接报错。
后来我也认真研究过 chezmoi、yadm、GNU Stow 这类 dotfiles 管理工具。这些工具本身很强大，chezmoi 甚至可以加密敏感文件。但对一个明确需求——同步一个.claude目录——引入一套完整的 dotfiles 管理语法，学习成本和维护成本都不低。如果你本来就在用 chezmoi，直接集成当然好；如果只是为了这个需求去学一套新工具，我认为性价比不高。
几种方案的直观对比：
| 方案 | 优点 | 缺点 | 适合谁 |
|---|---|---|---|
| 云盘自动同步 | 配置简单，几乎是零成本 | 凭据裸奔、冲突不可控、跨平台不稳定 | 单机使用者或临时救急 |
| dotfiles 管理工具 | 模板化、加密敏感信息、可回滚 | 学习曲线陡峭，配置复杂 | 已有 dotfiles 体系的人 |
| Git 仓库 + 符号链接 + 脚本 | 版本可追溯、冲突可合并、跨平台通用 | 需要自己搭脚本，有一点门槛 | 多机重度使用者、开发者 |
2.2 四机同步的架构拆解：仓库、目录、链接各司其职
我最终用的方案是三段式架构，每一段负责一件事：
- 中央仓库：一个任意 Git 托管平台上的私有仓库，四台机器只和它通信，不直接互相通信。
- 本地同步目录：每台机器上有一个
~/claude-sync，克隆中央仓库到本地，里面放一个config/目录，承载.claude的真实内容。 - 符号链接：把
~/.claude做成指向~/claude-sync/config的链接。这样 Claude Code 的代码无需任何改动，它照常读写~/.claude，但实际落盘位置已经是仓库所在目录。
这套架构的核心优势是 Git 自带的版本历史和冲突检测。每次同步都相当于一次 commit，任何一台机器上的改动都能被追踪；万一改坏了，git log和git checkout可以直接回滚到任意历史版本。符号链接则解决了“路径必须固定”的问题，Claude Code 不需要感知仓库的存在，进程完全无感。
我在四台环境差异很大的机器上跑过：一台 macOS 笔记本、一台 Linux 服务器、两台 Windows 机器（Windows 11 和 Windows 10），整体稳定性没有出过问题。跨平台唯一需要额外注意的是符号链接的创建方式，Windows 上确实比 Unix 系麻烦一点，这个我放到实操章节专门讲。
3. 从零搭建：四机同步配置体系的完整实操
3.1 准备同步仓库：把配置从“临时文件”变成“代码”
第一步，挑一台配置最完善的机器作为“母机”，在它上面把同步仓库建起来。我喜欢把仓库放在用户目录下一个独立的文件夹，避免跟其他项目混在一起：
mkdir -p ~/claude-sync/config cd ~/claude-sync git init -b main然后把.claude里需要同步的内容复制到config/。这里不建议cp -r ~/.claude/* config/一刀切，否则会把凭据和缓存一起搬进去。按我在 1.2 节划好的边界来：
# 在 ~/claude-sync 下执行 cp ~/.claude/settings.json ~/claude-sync/config/ cp ~/.claude/CLAUDE.md ~/claude-sync/config/ 2>/dev/null || true cp -r ~/.claude/skills ~/claude-sync/config/ 2>/dev/null || trueCLAUDE.md和skills目录不是每台机器都有，所以加2>/dev/null || true，没有就不报错。复制完之后在仓库根目录建.gitignore，我用的规则比较细：
# 凭据与密钥——永不提交 config/.credentials.json config/*.key *.pem # 会话历史和缓存 config/projects/ config/statsig/ config/todos/tmp/ # 系统残留 .DS_Store Thumbs.db然后提交并推到远端私有仓库：
git add -A git commit -m "chore: init claude code config sync" git remote add origin git@github.com:yourname/claude-sync.git git branch -M main git push -u origin main这里必须强调：仓库一定设为 private。同步配置文件里除了凭据，还可能包含内部 API 地址、模型配置等不适合公开的信息。我见过有人图省事直接推到 public 仓库，几分钟后settings.json里的内部服务和 token 就被人扫走了，这不是开玩笑。
3.2 处理敏感的登录凭据和模型 Token
先给结论：凭据不要走 Git，每台机器重新登录最省心。.credentials.json是登录态和 token，一旦泄露，别人可以拿你的身份去调用服务，损失不可控。
如果你在settings.json里配置了第三方模型的 base URL 和 token（比如切换 DeepSeek、GLM 这类模型时常见的env配置），建议把真实 token 抽到系统环境变量，settings.json里只写变量引用。比如这样：
{ "env": { "ANTHROPIC_BASE_URL": "$MY_BASE_URL", "ANTHROPIC_AUTH_TOKEN": "$MY_AUTH_TOKEN", "ANTHROPIC_MODEL": "$MY_MODEL_NAME" } }然后在各台机器的 shell 配置里定义这些环境变量，macOS/Linux 写在~/.zshrc或~/.bashrc，Windows 写在系统环境变量或 PowerShell profile 里。这样settings.json本身不含任何敏感信息，可以放心进 Git；换机器后只需要配置一次环境变量即可。
我踩过这个坑：最初把 token 直接写在settings.json里，同步到 Git 仓库后虽然仓库是私有的，但心里总不踏实。后来全部改成环境变量引用，配置文件干净了很多。统一用$VAR占位符还有一个好处：不同机器可以用不同的变量值，比如连不同的网关或者不同的模型服务，配置文件却完全一致，不会产生冲突。
3.3 创建符号链接：macOS/Linux 与 Windows 的两种姿势
配置搬进仓库后，母机上原来的~/.claude还占着位置，需要把它“让”出来。我的做法是先把原目录改名备份，再创建符号链接：
mv ~/.claude ~/.claude.bak.$(date +%Y%m%d%H%M%S) ln -s ~/claude-sync/config ~/.claude这样~/.claude就成了一个链接，Claude Code 对它的一切读写都会落到~/claude-sync/config。建议先别急着删备份，跑一遍claude确认设置、CLAUDE.md 都能正常读到，再处理备份。
Windows 上的符号链接有两个明显的坑。第一，普通权限下创建目录链接会报错，提示 “You do not have sufficient privilege”；第二，目录链接必须用/D参数。我的做法是在管理员 PowerShell 里执行：
Move-Item "$HOME\.claude" "$HOME\.claude.bak" New-Item -ItemType SymbolicLink -Path "$HOME\.claude" -Target "$HOME\claude-sync\config"如果不想每次开管理员终端，可以把 Windows 的“开发者模式”打开，之后创建符号链接就不再需要提权。这个方法对 Windows 11 和 Windows 10 都适用，实测下来很稳。
3.4 写一个 sync 脚本：一键完成多机合并
四台机器共用一个仓库，同步动作无非是“拉最新 → 提交改动 → 推到远端”。手动敲 Git 命令当然可以，但时间一长就会偷懒不执行。我写了一个脚本，在仓库目录里执行即可完成全部动作：
#!/usr/bin/env bash set -euo pipefail cd "$(dirname "$0")" REMOTE="origin" BRANCH="main" echo "==> pulling latest from $REMOTE/$BRANCH" git pull --rebase "$REMOTE" "$BRANCH" echo "==> staging changes" git add -A if git diff --cached --quiet; then echo "no changes, skip commit" else git commit -m "sync: $(date '+%Y-%m-%d %H:%M:%S')" fi git push "$REMOTE" "$BRANCH" echo "done"逻辑很简单：先pull --rebase把远端最新改动合并下来，再提交本机新改动并推送。set -euo pipefail是必须的，它能保证脚本在出错时立即退出，而不是继续执行产生错误提交。我写同步脚本吃过不少亏，最典型的就是忘了加set -e，pull失败后脚本还继续add和commit，把别人的或远端的改动一起卷进去，处理起来非常痛苦。
Windows 平台我同样准备了一个 PowerShell 版：
Set-Location $PSScriptRoot git pull --rebase origin main git add -A if (git diff --cached --quiet) { Write-Host "no changes" } else { git commit -m "sync: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')" } git push origin main执行脚本我封装成了一个 alias，在每台机器上都能用：
alias csync="bash ~/claude-sync/sync.sh"每台机器开工前和收工后各跑一次csync，配置基本不会丢。如果你愿意做得更自动一点，可以在 shell prompt 里挂一个 hook，每次进终端时自动检测仓库是否有未提交改动；macOS 也可以用 launchd 做定时任务，Windows 用任务计划程序。不过我实测下来，手动csync已经足够，因为真正需要同步的时机就是开始和结束工作两个节点。
3.5 新机器恢复：从 Git 克隆到能用只花三分钟
换新电脑时，不需要再手动复制任何文件。只要新机器装好了 Git 和 Claude Code，然后执行：
git clone git@github.com:yourname/claude-sync.git ~/claude-sync # 如果新机器已有 .claude，先备份 if [ -e "$HOME/.claude" ]; then mv "$HOME/.claude" "$HOME/.claude.bak.$(date +%Y%m%d%H%M%S)" fi ln -s ~/claude-sync/config ~/.claude这就是“换台电脑全没了”这个问题最彻底的解法：把配置纳入 Git 后，新机器从安装到恢复，中间流程不超过三分钟，而且不用考虑从哪里拷贝旧文件的问题，只要克隆仓库就行。
我可以把这几步固化成一个install.sh放在仓库根目录，以后新机器直接一条命令跑完：
#!/usr/bin/env bash set -euo pipefail REPO_URL="git@github.com:yourname/claude-sync.git" INSTALL_DIR="$HOME/claude-sync" [ -d "$INSTALL_DIR" ] || git clone "$REPO_URL" "$INSTALL_DIR" if [ -e "$HOME/.claude" ] && [ ! -L "$HOME/.claude" ]; then mv "$HOME/.claude" "$HOME/.claude.bak.$(date +%Y%m%d%H%M%S)" fi ln -sfn "$INSTALL_DIR/config" "$HOME/.claude" echo "done"ln -sfn里的-f会在已有链接时强制替换，所以我加了判断，只有“非链接的目录”才备份，避免误删已有配置。
4. 跑了一段时间后：常见问题与避坑实录
4.1 会话历史要不要同步？我的取舍
会话历史是很多人最想同步的东西，毕竟不想把聊到一半的需求换个机器重新讲一遍。我的建议是：可以同步，但要有策略。
如果确实需要跨机器接着聊，就把projects/目录保留进 Git。但有两点必须接受：第一，全部历史同步会让仓库迅速膨胀，需要定期清理旧的.jsonl会话文件，我建议最多保留最近一个月；第二，不同操作系统的路径编码规则不一样，Claude Code 在projects/里用项目绝对路径来做目录编码，Windows 的C:\Users\xxx和 macOS 的/Users/xxx编码结果完全不同，跨平台之后基本找不到对应会话。
我的实际做法是不同步projects/，因为 Claude Code 本身有优雅的上下文恢复能力，配合全局CLAUDE.md把项目关键信息写清楚，换机器后早点描述一下就能快速接上。会话内容属于“丢了会可惜但不会致命”的数据，配置和记忆才是核心资产，没必要为同步会话历史付出膨胀和冲突的代价。
4.2 两台机器同时改配置，冲突怎么合并
Git 有冲突检测机制，这意味着多机同时改动一个文件时你需要处理冲突。比如我在公司电脑改了settings.json的权限策略，家里电脑同时改了默认模型，两边都 push 的时候，后 push 的那台会收到冲突提示。
我的处理经验是：pull --rebase后如果提示冲突，不要慌，直接用编辑器打开冲突文件，手动合并两边内容。settings.json这种 JSON 的冲突通常集中在某几个字段，合并完保存，然后执行git add和git rebase --continue，最后再push一次即可。
减少冲突的根本方法是让各机器之间的差异尽量小。机器相关的状态，比如当前主题、窗口大小、界面设置，不要写进同步的settings.json；这些属于本地状态，留在各台的本地配置里就好。同步仓库里只保留真正愿意在每台机器上保持一致的内容。
4.3 符号链接失效、skills 不生效、启动报错的排查顺序
同步后如果claude启动报错，或者感觉配置没生效，我有一套固定的排查顺序，分享出来供参考。
第一步，确认~/.claude到底是不是符号链接：
ls -la ~/.claude file ~/.claude如果输出里没有显示symbolic link，说明初始化脚本没生效，或者被某次操作替换成了真实目录，重新执行 install 脚本即可。
第二步，检查settings.json是否是合法的 JSON：
python3 -c "import json; json.load(open('$HOME/.claude/settings.json'))"多数启动失败都是因为配置文件里混入了注释、尾逗号，或者某个字段在另一台机器上的版本不识别。JSON 报错时，把配置文件的报错信息读完整，基本能定位到具体字段。
第三步，如果 JSON 没问题但 skills 不生效，查看skills/目录结构是否符合 Claude Code 的约定格式：
find ~/.claude/skills -maxdepth 2 -name "SKILL.md"每个 skill 必须是一个独立子目录，里面有一个SKILL.md作为入口文件。如果SKILL.md的路径不对，或者目录权限有问题，Claude Code 会静默跳过，不会报错，但你就是发现技能不出现。这类问题排查起来最容易抓狂，所以我把目录格式检查放在了常见问题清单里。
提示：不要在生产环境机器上直接删
.claude目录。先备份再操作，哪怕只是mv ~/.claude ~/.claude.tmp，也比直接rm安全得多。
4.4 一些容易被忽略的控制细节
最后补充几个我跑四机方案时容易被忽略的细节。
第一个是 Git 提交信息。我的 sync 脚本用的是时间戳，但如果想追溯“某台机器某次改了什么”，建议在提交信息里加主机名或自定义标识。比如把 commit message 改成sync: hostname - $(date)，这样git log里一眼就能看出来是哪台机器提交的。
第二个是环境变量文件的管理。.zshrc、.bashrc、PowerShell profile 这些文件本身也可以纳入同一个仓库，比如放到shell/目录，用同样的符号链接方式挂载。不过这会牵扯到整机环境管理，建议循序渐进，先把.claude控制好，再考虑扩展到 shell 配置。
第三个是网络代理问题。在多机环境下，每台机器访问外网服务的网络条件不同，如果某台机器的settings.json里写死了超时时间或重试次数，可能在某些网络环境下表现很差。我建议把这些网络相关参数留空，让 Claude Code 使用默认值，各家机器自行处理网络连通性，不要把这些写在同步配置里。
第四个是团队场景的扩展。如果你的团队有多个成员都在用 Claude Code，可以把这套仓库改成内部共享，只同步公用的CLAUDE.md和skills/，把各自的settings.json排除掉。团队规范、常用技能一键下发，又不会互相污染权限配置。这是我最近在跑的一个扩展玩法，实测比群里发文件高效得多。
我用这套四机同步方案跑了小半年，最直接的感受是：工具链本身的“配置管理”这件事，值得像管理项目代码一样认真对待。Git 不只管代码，还能管配置、管文档、管一切需要版本追踪的东西。现在我在任何一台机器上打开终端，跑一下csync，然后继续用 Claude Code，就像从来没有离开过这台机器一样。
