上周我在老家电脑上打开终端敲下claude回车。等我的不是一个熟悉的项目上下文而是一个全新欢迎页。那一刻我意识到之前那台工作机上攒的 skills、CLAUDE.md、命令别名、权限白名单、第三方模型配置全部像没存在过一样。我在办公室里花了三个下午调好的 Claude Code 环境换台电脑就归零了。这事不是个例。Claude Code 这类终端 AI 编程工具的配置几乎全在本地账号登录只能保住你的订阅和额度本地目录里的会话、技能、配置统统不会跟着账号走。尤其是像我这种需要在台式机、办公笔记本、家里轻薄本、客厅 Linux 小主机之间来回切换的人如果不在同步上花点心思每次换机都是一次“失忆”。这篇就是把我的四机同步方案完整拆开讲一遍哪些文件该同步、哪些文件碰都不要碰、怎么用一条命令让新机器恢复成老机器、以及不同平台之间那堆防不胜防的小坑。内容偏实操适合已经在用 Claude Code、且不止一台设备的开发者。看完你可以直接照抄也可以根据这套思路魔改成自己的版本。1. 换台电脑Claude Code 为什么像被格式化过1.1 我的“失忆现场”我那天原本的计划很简单回老家之后继续在公司没写完的一个内部工具项目。项目代码已经推到远端仓库了我以为把仓库 clone 下来就万事大吉。结果claude一启动它既不记得我项目里的背景约束也不再认识我之前给它装的技能。更尴尬的是它连基本的行为习惯都丢了——我在公司机器上早就配好了权限白名单哪些命令可以直接执行、哪些文件允许读写都是从踩坑里一点点放开的。换到老家这台机器之后Claude Code 又变回了那个“每走一步都要问我一次”的新手状态。我当时第一反应是这东西不是有账号体系吗登录同一个账号怎么配置不跟着走后来把~/.claude目录翻了个底朝天才彻底搞明白——账号归账号配置归配置。Claude Code 的设计里账号负责认证和计费剩下的几乎全部是本地的。你在项目里写过的那句“所有日志文件放在 logs/ 下不要动 public/assets”存在CLAUDE.md里你通过技能的安装目录存在~/.claude/skills下你授权过的工具清单写在settings.json里。这些文件才是 Claude Code 真正“认识你”的基础。1.2 真相账号管的是额度不是配置想明白这一点之后我又去翻了一圈相关资料确认了 Claude Code 的同步边界它能跟着账号走的只有一个合法的登录态和订阅身份本地的一切运行状态都是机器专属的。这个概念其实和很多开发工具是一致的但 Claude Code 特别容易让人误以为它有云同步能力。因为它是一个 AI 编程工具给人的直觉是“AI 应该记住我”。可它的记忆分两层第一层是模型上下文里的记忆也就是对话过程中模型看到的项目文件、历史消息这些是临时的、按会话存在的第二层是本机的持久化记忆包括你的CLAUDE.md、skills、commands、settings、会话历史这些全都落在本地文件系统。想清楚这两层之后问题就转化了我需要的不是让 Anthropic 帮我记住什么而是自己想办法把第二层“本机文件”在不同设备之间搬运和同步。尤其是现在不少人还会给 Claude Code 接第三方模型比如 DeepSeek、GLM或者用社区工具做多模型切换。这些配置通常写在环境变量或settings.json里同样只存在本机。环境变量还能在 shell 配置文件里找回来但settings.json里的各种模型参数、系统提示词、工具权限一旦换机就是全部重来。所以“换台电脑 Claude Code 全没了”这个问题的本质不是一个 bug而是本地优先架构下的必然结果。解决思路也很朴素像管理 dotfiles 一样去管理.claude目录。2. 同步之前先搞清 Claude Code 到底在你机器上放了什么2.1 ~/.claude 全家桶拆解要制定同步方案第一步不是急着建仓库而是把你机器上的~/.claude目录拆开看一遍。我之后清理了大量教程类文章也看了自己目录里实际的文件最终把 Claude Code 在本地的数据分成以下几类。以我目前的版本为例~/.claude下面常见的内容包括路径内容同步价值~/.claude/CLAUDE.md用户级全局记忆文件跨项目的通用约束高~/.claude/settings.json用户级配置模型、权限、行为开关高需脱敏~/.claude/commands/自定义斜杠命令比如/review、/deploy高~/.claude/skills/技能目录社区安装的各种 skills高~/.claude/agents/自定义 agent 定义高~/.claude/todos/任务清单跨会话维护中~/.claude/projects/按项目路径编码的会话记录JSONL 格式低按需~/.claude/history.jsonl全局会话历史索引低~/.claude/shell-snapshots/终端会话快照用于恢复 shell 状态低且含敏感信息~/.claude/.statsig/实验开关等临时状态忽略~/.claude/.credentials.json登录凭据或密钥忽略并保护项目级的CLAUDE.md不在这个目录里它跟着项目仓库走。所以如果项目代码存在 Git 仓库里项目级记忆天然就已经在同步了。真正容易被忽略的是用户级的~/.claude/CLAUDE.md以及上面这些全局配置。这里说一个很多人不知道的点projects/目录下的会话文件文件名是用项目路径编码过的。比如你/home/me/work/app下的项目会生成一个类似-home-me-work-app.jsonl的文件。也就是说Claude Code 判断“这是哪个项目的会话”靠的是绝对路径而不是 Git remote。这也是为什么换机器之后即使你把项目 clone 到同一个仓库它也不会自动关联之前的会话——因为在新机器上项目路径可能完全不一样。2.2 哪些必须同步哪些同步反而会出事我一开始脑子一热想过干脆把整个~/.claude目录塞进云盘一了百了。后来发现这是最蠢的方案原因有四个第一shell-snapshots/目录里可能有终端里的明文信息。Claude Code 为了恢复 shell 状态会把环境变量、历史命令之类的东西记录下来。这东西同步到别的机器既没有价值还有泄露风险。第二projects/目录大且敏感。我用了两个月后这个目录已经有三四百 MB。里面是完整对话记录包含粘贴过的代码、API 请求、错误日志甚至可能包含密钥片段。把它塞进同步仓库仓库很快会爆炸而且等于把机密文件复制到所有设备上。第三.statsig、日志文件这类临时状态同步过去毫无意义。Claude Code 在每台机器上会自己重建这些内容你强行同步只会制造冲突。第四settings.json里很可能有你不该提交的密钥。很多教程会让你在settings.json里直接写apiKey或者第三方服务的 token。如果你不做脱敏处理就拉进同步仓库等于把密钥广播给所有 clone 这个仓库的人。所以我的原则是配置和技能要同步数据和秘密不硬同步。具体到文件级别我最终选择同步的是这些CLAUDE.mdsettings.json脱敏后敏感字段用环境变量替代commands/skills/agents/todos/可选因为更新频繁容易产生冲突所有这些加起来实际体积还不到 10MB非常适合放进一个 Git 私有仓库。3. 四机同步方案的整体设计与目录策略3.1 为什么选 Git 私有仓库做“配置主源”确定要同步的内容之后接下来一个问题用什么做同步通道市面上无非三种选择网盘iCloud、OneDrive、坚果云、P2P 同步工具Syncthing、Git 私有仓库。我四台机器分别是 Windows、macOS、Linux 混着用网盘客户端在这三个平台上的行为差异很大而且在后台实时同步文件时很容易把我正在写的settings.json同步到一半导致配置损坏。Syncthing 整套方案我也试过后文会详细讲。这里先说我放弃它做主力通道的直接原因它倾向于“设备之间自由同步”一旦一台机器离线另一台机器改了配置等它上线后很容易因为双向同步产生冲突文件而且冲突解决逻辑不透明对于文本配置来说并不友好。Git 私有仓库最大的优势是同步逻辑是人类可读的改了什么、什么时候改的、在哪台机器上改的全都有迹可循。就算两台机器同时改同一个文件Git 也能明确告诉你冲突了而不是静悄悄地把文件覆盖掉。我最终选的方案就是一个私有 Git 仓库当“配置主源”每台机器都只和这个仓库保持同步机器之间不直接对话。仓库结构大致是这样的claude-code-sync/ ├── CLAUDE.md ├── settings.json ├── commands/ │ ├── review.md │ └── deploy.md ├── skills/ │ └── ... ├── agents/ │ └── ... ├── scripts/ │ └── bootstrap.sh ├── scripts/ │ └── bootstrap.ps1 └── .env.example这里有两个关键设计一是settings.json里不写真实密钥统一用${env:XXX}或${env:XXX}这类方式读取环境变量每台机器各自维护一份.env二是保留一份.env.example作为新机器的配置清单告诉你在哪里填哪些 key。3.2 用符号链接把真实配置“接”进仓库仓库建好之后怎么让 Claude Code 用它最粗暴的做法是每台机器 clone 仓库之后复制文件到~/.claude。问题是复制过去之后仓库和实际使用目录就是两份文件。你在这台机器上改配置时到底改的是哪一份很容易分心然后忘记提交。更好的做法是符号链接symlink。我把~/.claude里的settings.json、commands、skills、agents、CLAUDE.md分别做成符号链接指向仓库里的对应文件或目录。这样 Claude Code 在运行时实际读到的就是仓库里的文件本机改配置等于直接改仓库然后整个流程就变成“改仓库、提交、push”。这里有一个容易翻车的细节不能把整个~/.claude目录做成软链。因为.claude目录里还有大量不需要同步的内容比如.statsig、shell-snapshots、projects。如果整目录软链你就得把它们全部纳入 Git 管理不然新机器上会缺目录导致 Claude Code 启动异常。我采用的方式是分项目录软链。以 macOS/Linux 为例mkdir -p ~/.claude ln -sfn ~/code/claude-code-sync/CLAUDE.md ~/.claude/CLAUDE.md ln -sfn ~/code/claude-code-sync/settings.json ~/.claude/settings.json ln -sfn ~/code/claude-code-sync/commands ~/.claude/commands ln -sfn ~/code/claude-code-sync/skills ~/.claude/skills ln -sfn ~/code/claude-code-sync/agents ~/.claude/agents注意skills、commands、agents这几个目录在第一次安装 Claude Code 时不一定存在。如果不存在软链会失败或者行为奇怪。我的脚本里会先检查如果原来没有这些目录就直接创建目录然后把仓库里的内容链接过去。如果原来已经有目录了但里面没有需要保留的本地数据直接rm -rf再链也不亏。这样做的收益很明显任何一台机器上安装了新 skill或者改了一条 command它直接落在仓库里其它机器只要git pull就自动生效不需要再拷贝一次。4. 落地执行同步仓库、bootstrap 脚本与跨平台处理4.1 初始化仓库与筛选文件先别急着在每台机器上配软链第一件事是初始化主仓库。我在Github上建了一个名为claude-code-sync的私有仓库然后在第一台机器上把它 clone 到~/code/claude-code-sync。接着把需要同步的文件复制进去。注意settings.json先复制过去之后要立刻打开它把里面的敏感字段改成环境变量引用。比如原先是{ apiKeyHelper: ..., model: claude-sonnet-4-20250514 }我会改成{ model: claude-sonnet-4-20250514, apiKeyHelper: env:ANTHROPIC_API_KEY }不同版本对apiKeyHelper的写法可能不一样但原理是一样的不要在配置文件里留下明文密钥。如果你是通过ANTHROPIC_BASE_URL接第三方模型也是同样的处理方式把 URL 和 key 都挪到环境变量里。然后我添加了一个.gitignore明确忽略不该进仓库的东西.env *.log .DS_Store再强行补一条目录排除规则防止有人误把整个projects目录拖进来projects/ shell-snapshots/ .statsig/ credentials*关于todos/我一开始是同步的后来发现它更新太频繁两台机器同时工作时会产生不少无意义的提交记录。最终我把它从仓库移除了只在主力机器上保留。如果你也用 Git 管理建议先忍住不要同步todos/等确实有跨设备待办需求再加回来。4.2 bootstrap 脚本从零到能跑的三步仓库有了接下来是让新机器快速接入。我写了两个脚本一个给 bash/zshmacOS、Linux、WSL 都能用一个给 PowerShellWindows。bash 脚本核心逻辑#!/usr/bin/env bash set -euo pipefail REPO_DIR$HOME/code/claude-code-sync CLAUDE_DIR$HOME/.claude if [ ! -d $REPO_DIR ]; then echo 仓库不存在请先 clone 到 $REPO_DIR exit 1 fi mkdir -p $CLAUDE_DIR link_item() { local name$1 local target$REPO_DIR/$name local link_path$CLAUDE_DIR/$name if [ -e $link_path ] [ ! -L $link_path ]; then mv $link_path $link_path.bak.$(date %s) echo 备份原有 $name 到 $link_path.bak.* fi ln -sfn $target $link_path echo 已链接 $name } link_item CLAUDE.md link_item settings.json link_item commands link_item skills link_item agents这段脚本有几个细节值得说明set -euo pipefail保证中间任何一步失败都会停下不会留下半成品。遇到已有文件但又不是符号链接的情况我没有直接删而是先备份。这个非常重要因为新机器上如果已经跑过一次 Claude Code它可能已经生成了自带的settings.json直接删掉会导致你丢东西。ln -sfn里的-f是为了强制替换-n是防止目标是一个目录时把链接创建到目录内部去。PowerShell 版本的思路一样只是符号链接命令不同New-Item -ItemType SymbolicLink -Path $env:USERPROFILE\.claude\skills -Target $env:USERPROFILE\code\claude-code-sync\skillsWindows 上创建符号链接有几个前置条件后面单独讲。接入新机器的完整流程被我压缩成了三句话装好 Claude Code 本体跑过一次让目录结构生成clone 我的同步仓库到~/code/claude-code-sync运行 bootstrap 脚本然后配置.env环境变量。整个流程熟练之后只需要两三分钟新机器就能拥有和老机器几乎一致的 Claude Code 环境。4.3 Windows、macOS、Linux 三端差异处理这套方案真正的难点不在脚本本身而在平台差异。我在四台机器上踩了一圈总结出下面几个高频坑。第一个坑Windows 上的符号链接权限。默认情况下普通用户在 Windows 上执行New-Item -ItemType SymbolicLink会报错提示“你没有足够的权限执行此操作”。这不是 PowerShell 的问题而是 Windows 的安全策略。解决办法有两个打开“开发者模式”设置 → 隐私和安全性 → 开发者选项 → 打开“开发人员模式”。开启后普通用户就能创建符号链接。或者用管理员身份的终端执行脚本。我最终选择开启开发者模式因为这样不用每次都以管理员身份运行。第二个坑Windows 下的 PowerShell 执行策略。运行我的bootstrap.ps1脚本可能被系统拦下来。你可以用Set-ExecutionPolicy -Scope CurrentUser RemoteSigned放宽本用户的执行限制但要注意这是有安全影响的。如果只是临时跑一次我建议直接在当前 PowerShell 窗口里复制脚本逐行执行。第三个坑macOS 和 Linux 的~/展开差异。bash 脚本里我用了$HOME而不是~就是为了避免在脚本里因为引号问题导致~不展开。这个坑在写 cron 任务时尤其明显交互式 shell 里正常脚本里就翻车。第四个坑换行符。Windows 上如果用了 Git 默认配置checkout 仓库时可能会把settings.json的换行符转成 CRLF。Claude Code 读 JSON 一般不受影响但CLAUDE.md是纯文本如果换行符变了在最坏情况下会导致 markdown 格式错乱。我的解决方式是在同步仓库根目录添加.gitattributes* textauto *.json text eollf *.md text eollf *.sh text eollf这样无论在哪台机器上 checkout关键的 JSON 和 Markdown 文件都会保持 LF 换行。第五个坑环境变量怎么跨平台统一。不同平台的 shell 配置不一样。macOS 和 Linux 我写在~/.zshrc或~/.bashrcWindows 上我写在 PowerShell$PROFILE里。内容基本一致export ANTHROPIC_MODELclaude-sonnet-4-20250514 export ANTHROPIC_API_KEYsk-ant-... # 如果你用第三方模型再加 export ANTHROPIC_BASE_URLhttps://api.example.com然后把.env.example放进同步仓库每一台机器 clone 之后照着填一遍。注意.env本身不进仓库每台机器的 key 可以不同这样反而更安全——比如家用机用一个限制更严格的 key服务器上用另一个。5. 会话历史与私有数据的取舍我不建议全量同步5.1 让 git 承载全部会话这是坑写完基础同步方案之后我第一个想解决的问题就是新机器上没有之前的对话记录Claude Code 对我的项目一无所知。于是我想过把~/.claude/projects/目录也纳入同步。结果试了两天立即放弃了。首先是体积问题。一次完整会话的 JSONL 文件可能是几十 KB 到几 MB我用了两个月之后整个projects/目录已经有几百 MB。Git 仓库就算压缩也会变得越来越大每次push都卡顿何况里面还有大量重复的代码片段。其次是隐私问题。projects/里的 JSONL 是对话全文里面经常包含我不小心粘贴进去的密码、内部 API 的完整请求、客户数据字段。把这些内容同步到我所有设备上的仓库里等于扩大了敏感信息的暴露面。我的原则是敏感数据能少复制一份就少复制一份。第三是路径匹配问题这是最隐蔽的坑。前面说过Claude Code 的会话记录按项目绝对路径编码。你在公司机器的/Users/me/work/app下工作会话文件叫-Users-me-work-app.jsonl。到了家里项目如果放在/Users/me/Documents/work/app即使你把同一个项目 clone 下来Claude Code 也会认为这是一个完全不同的项目原来的会话记录根本对不上。所以即使我把projects/全量同步过去只要两台机器项目路径不一样那些会话在新机器上依然是“不存在”的。5.2 按需迁移会话而不是硬同步既然不是继续全量同步那我怎么在换机后继续之前的工作我的方案分两步。第一步统一项目路径。我在所有机器上都约定项目放在同一个位置的同一个目录名下面比如统一放在~/work/project-name。这样虽然不同系统的$HOME路径前缀不一样但项目内相对路径一致。至少在有需要时我可以手工迁移一条会话。第二步按需手工迁移。如果我在公司电脑上处理到一半的任务回家还想继续我不会同步整个projects/而是只导出那一个项目的 JSONL 文件。具体操作在源机器上找到对应的会话文件比如~/.claude/projects/-Users-me-work-app.jsonl把它安全复制到新机器上同样的~/.claude/projects/目录下启动claude用--continue或者--resume找到最近的会话。这样做的好处是我只复制了必要的那一条会话体积小、暴露面小而且因为项目路径一致Claude Code 能正确识别。如果项目路径不一致我宁可在新机器上重新开一个会话把项目的CLAUDE.md和关键 README 丢给它让它快速重新进入状态。要补充的是CLAUDE.md才是跨机器“记忆”的正主。只要项目里的CLAUDE.md写得够好新机器重新开会话的成本是很低的。我后来刻意花时间把项目的CLAUDE.md写得更细同步需求自然就降下来了。6. 多机日常协作与冲突处理6.1 同时改配置的 Git 冲突怎么解决方案跑起来之后真正会咬人的是冲突。我手里的四台机器并不是一台闲置一台用而是可能同时开着。比如我在办公电脑上装了一个新 skill晚上回家看到家里电脑上正好也改了一个自定义 command。两台机器都还没来得及push于是第二天办公电脑pull的时候冲突就来了。Git 的冲突处理对于文本配置来说不算难但要有流程。我自己的习惯是每次准备提交前先git pull --rebase把远端提交拉到本地再变基避免出现 merge commit 把历史搅乱。如果真冲突了git status看是哪个文件冲突。settings.json冲突最常见因为它是单文件。打开冲突文件把两边的修改手动合并。如果只是某一行模型名不一样选最新的那个就行如果是权限列表冲突我会把两边的allow数组都合并进来。合并完git add、git rebase --continue然后git push。这里我要说一个反直觉的结论冲突并不完全是坏事。因为配置文件的冲突不会影响代码运行它反而会逼着你去想“我在其他机器上到底改了些什么”很多时候能发现自己重复安装了两个相似技能的冗余。为了减少冲突频率我还用了另一个策略为settings.json配置一个自定义 merge driver。简单来说就是让 Git 在合并这个文件时不要逐行 diff而是以“一方优先、另一方丢弃”的方式处理。但自定义 merge driver 的配置有点繁琐且不一定适合所有人我这里不展开。对大多数单人或双人使用场景手动处理冲突已经足够了。6.2 日常同步流程和验证清单把同步流程变成一个肌肉记忆我的做法是把它压缩成一条命令。在 shell 配置里加了一个 aliasalias csynccd ~/code/claude-code-sync git pull --rebase git add -A git commit -m sync $(date) git push每次在一台机器上改完配置、装完 skill、调完命令退出 Claude Code 之后顺手敲一句csync配置就会被兜住。这个 alias 很糙但对个人使用场景来说非常够用。到了另一台机器直接csync一次然后重启 Claude Code一切就同步了。这里要特别提醒一点Claude Code 在运行状态中可能会缓存配置。如果你在一台机器上修改了settings.json推到另一台机器后那台机器正开着的 Claude Code 不会立刻感知到。需要退出重进。如果是改了CLAUDE.md通常新的会话会自动读取但正在进行的会话不会更新。新机器跑完 bootstrap 之后我建议按下面这个清单验证一遍验证项方法预期结果全局配置生效在任意目录执行claude观察启动行为模型、权限、问候语与旧机器一致技能同步成功进入对话后输入/help或触发技能安装列表能看到仓库里同步过来的 skills自定义命令可用输入/review或其他自定义斜杠命令正常执行全局 CLAUDE.md 生效新建一个临时项目问它“我们的项目有哪些约定”能复述出 CLAUDE.md 中的关键约束环境变量正确通过对话或日志确认模型接入正常第三方模型能正常响应这套验证看起来繁琐其实两分钟就能跑完。我后来已经熟练到只要看启动时的模型名和能自动补全的命令列表就知道同步成没成功。7. 这套方案的边界与替代方案7.1 四个最容易被忽略的坑方案讲了这么多说几个我自己踩过、但网上很少被提到的坑。坑一settings.json可能被工具本身改写。Claude Code 更新版本之后有时会往settings.json里写入新的配置项。如果你的settings.json是一个符号链接这没问题它会直接在仓库文件里写。但如果新版本在升级时“好心”地备份了一下旧配置它会复制出一个.bak文件而这个文件如果被 Git 跟踪了目录里就会出现大量奇怪的历史快照。我的处理是.gitignore里把*.bak*全局忽略掉。坑二Windows 上杀毒软件可能拦截符号链接。Windows Defender 或者其他安全软件有时会把符号链接当成可疑行为。尤其当你的开发目录和配置目录不在同一个盘符时创建链接偶尔会被拦截。我没有找到完美的解决方案只能说尽量让仓库路径固定少换位置。如果一个链接建立失败优先检查是不是杀毒软件拦截了New-Item。坑三不要把.env.example和真实.env放混。我有一次在同步仓库里误提交了真实的.env文件虽然仓库是私有的但这也是一次典型的安全失守。后来我在.gitignore里同时忽略了.env和.env.*但随后发现连.env.example也被忽略了。改成了这样.env .env.* !.env.example又把.env.example强制保留。这个细节看起来不起眼但能防止把示例文件弄丢。坑四多机同时操作同一个项目时要格外小心。配置同步没问题但如果我在两台机器上同时改同一个代码项目Claude Code 的会话状态会非常混乱。它基于本地文件目录工作不会知道另一台机器上发生了什么。最后合并代码倒不怕怕的是它会用旧的代码状态给你生成修改建议。所以我现在给自己定了一条规矩**同一个项目同一时间只在一台机器上做 AI 辅助开发。**另一台机器可以看代码、写代码但不跑 Claude Code。7.2 不满足的场景怎么办云盘、Syncthing 等备选Git 符号链接这套方案不是银弹。它主要的短板是**同步是手动的不实时。**如果你只有一台主力机、一台备用机手动push/pull完全够用。如果你需要两台机器近乎实时地共享同一个配置状态或者你不想维护 Git 仓库可以考虑另外两种方案。云盘同步把~/.claude下面需要同步的目录放进 iCloud、OneDrive、坚果云这类网盘的同步目录里再用符号链接指过去。优点是没有 Git 的学习成本缺点同样明显——网盘客户端在后台同步时可能在你写入配置的半途锁文件导致配置损坏而且如果你不小心把整个.claude目录放进去等它同步几个 GB 的会话记录时会让你怀疑人生。真要这么用建议只放CLAUDE.md和skills/这种低变更目录。Syncthing在自建设备之间做近实时同步不经过第三方服务器。它比网盘可控也比 Git 实时。我之前试过用 Syncthing 同步~/.claude跑了一周最终败给了冲突文件。Syncthing 在遇到双端同时修改时会保留一个*.sync-conflict-*文件配置目录里到处都是这种文件Claude Code 虽然不理会它们但看着很难受。所以我的结论是如果你很懒只想同步 skills 和 CLAUDE.md用 Syncthing 也能将就。如果你想完整复刻我的方案、且能接受手动同步Git 私有仓库是最稳的。回到开头那个场景。现在我回老家只需要花两分钟跑一遍 bootstrap然后csync一下整个 Claude Code 就恢复了我在公司电脑上的样子。skills 全在CLAUDE.md 全在权限白名单全在第三方模型的接入也不用手动配。这个过程里真正让我觉得有价值的不只是同步本身而是我被迫把自己的配置“显式化”了——以前那些零散写在某个角落的配置现在都变成了仓库里看得见、管得住的文本文件。最后再分享一个小经验**先别追求完美从只同步CLAUDE.md和skills开始。**把这一小步跑通之后你自然会理解哪些配置值得同步、哪些数据需要单独处理。等你想明白这一点再上 Git 仓库、再写 bootstrap 脚本效率和满意度都会比一上来就折腾全套高得多。