把 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 gitgithub.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或~/.bashrcWindows 写在系统环境变量或 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) REMOTEorigin BRANCHmain 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 -epull失败后脚本还继续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 csyncbash ~/claude-sync/sync.sh每台机器开工前和收工后各跑一次csync配置基本不会丢。如果你愿意做得更自动一点可以在 shell prompt 里挂一个 hook每次进终端时自动检测仓库是否有未提交改动macOS 也可以用 launchd 做定时任务Windows 用任务计划程序。不过我实测下来手动csync已经足够因为真正需要同步的时机就是开始和结束工作两个节点。3.5 新机器恢复从 Git 克隆到能用只花三分钟换新电脑时不需要再手动复制任何文件。只要新机器装好了 Git 和 Claude Code然后执行git clone gitgithub.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_URLgitgithub.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 doneln -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是否是合法的 JSONpython3 -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就像从来没有离开过这台机器一样。
用Git+符号链接实现Claude Code多机同步：告别换电脑配置全丢
把 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 gitgithub.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或~/.bashrcWindows 写在系统环境变量或 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) REMOTEorigin BRANCHmain 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 -epull失败后脚本还继续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 csyncbash ~/claude-sync/sync.sh每台机器开工前和收工后各跑一次csync配置基本不会丢。如果你愿意做得更自动一点可以在 shell prompt 里挂一个 hook每次进终端时自动检测仓库是否有未提交改动macOS 也可以用 launchd 做定时任务Windows 用任务计划程序。不过我实测下来手动csync已经足够因为真正需要同步的时机就是开始和结束工作两个节点。3.5 新机器恢复从 Git 克隆到能用只花三分钟换新电脑时不需要再手动复制任何文件。只要新机器装好了 Git 和 Claude Code然后执行git clone gitgithub.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_URLgitgithub.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 doneln -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是否是合法的 JSONpython3 -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就像从来没有离开过这台机器一样。