claude-obsidian Windows 与 WSL 平台指南只读原生、全能力 WSL 与排障实战【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidian本篇基于仓库中的 Windows/WSL 官方指南讲清楚 claude-obsidian 在 Windows 生态下的能力边界原生 Windows 是“只读平台”WSL 才是“全能力平台”。读完后你将掌握各平台能力矩阵、UNSUPPORTED_PLATFORM/UNSAFE_VAULT_IDENTITY/PLAN_CHANGED三类错误的源码级成因、Claude Code hooks 在 Windows 上依赖python3的机制以及一套可复用的 WSL 排障清单与跨边界工作流。平台能力矩阵哪些命令能在哪跑官方指南docs/windows-wsl.md给出的支持矩阵如下本文所有结论均以此为准能力WSL / Linux / macOS原生 Windows含 Git Bash检查、dry-run 预览、检索retrieval支持支持Vault 写入transaction apply、init、adopt、migrate、capture apply、mode set支持不支持 — 拒绝并报错UNSUPPORTED_PLATFORMCapture 队列命令包括只读的capture queue list支持不支持 — 当前一律拒绝上游已在 issue #151 跟踪Git 检查点checkpoint仅 Linux 和 macOS不支持Bash 安装脚本与 shell 测试套件支持不支持POSIX 专属Claude Code hooksSessionStart、Stop支持开箱即用部分支持要求python3在PATH上见下文也就是说在原生 Windows 上你可以放心做“看”的操作inspect、dry-run 预览、retrieve但所有“改”的操作都会被平台门禁platform gate在产生任何副作用之前直接拒绝WSL 里则是全功能。稳定文件身份是 Vault 的硬性前提除了操作系统本身的限制Vault 所在文件系统的“文件身份”稳定性也决定写入是否被放行NTFS 可以FAT/exFAT 卷典型如 U 盘和部分网络共享卷会被拒绝错误码为UNSAFE_VAULT_IDENTITY——解决办法是把 Vault 移到 NTFS 卷或放进 WSL 内部文件系统操作。从源码看这条拒绝来自 claude_obsidian/transaction.py 中的_require_stable_identity()当stat结果的st_ino为 0说明文件系统不暴露稳定的 inode 身份时抛出UNSAFE_VAULT_IDENTITY错误信息明确提示 “FAT/exFAT/some network shares; use an NTFS volume or WSL”。同一错误码还覆盖了“无法 pin 住 Vault 父目录”“无法枚举 Vault 父目录”等身份不可信的情形见 transaction.py 中的多处抛出点即任何一步无法确认“这个目录始终是这个目录”写入都会 fail closed。Claude Code hooks 与 Windows 上的 python3claude-obsidian 通过 hooks/hooks.json 注册了SessionStart与Stop两个 Claude Code 生命周期钩子配置形态如下exec-form 命令钩子{ type: command, command: python3, args: [ ${CLAUDE_PLUGIN_ROOT}/scripts/claude-obsidian.py, hook, session-start ], timeout: 5 }关键点在于command: python3加一个args数组Claude Code 会像可执行文件一样直接在PATH上解析python3并 spawn没有 shell 参与因此.batshim、shell alias 函数、shell profile 全部不会被参考。WSL 与大多数 Linux/macOS 的 Python 安装默认提供PATH上的python3所以那些环境下 hooks 无需额外配置即可工作。原生 Windows 常常没有常见有两种情形python.org 官方安装包装出来的是python.exe而不是python3.exe。对策有三种任选在解释器之前的PATH位置放一个python3.exeshim安装提供python3.exe的发行版或者干脆从 WSL 里运行 Claude Code让 hooks 解析到 WSL 的python3。Microsoft Store 版 Python其python3应用执行别名app execution alias可能只是一个会打开商店的 stub而不是真正的解释器。需要在 Windows 设置中禁用python3应用执行别名然后从 python.org 安装 Python 或在 WSL 中安装并确认真正的解释器在PATH上。还有一个值得注意的失败语义当python3无法被解析时Claude Code 根本起不了钩子进程claude-obsidian 自己的代码永远不会执行因而也无法输出任何诊断信息。此时SessionStart的上下文注入和Stop的恢复警告都会“安静地缺席”。但这只影响可选的 hook 路径——skills 与 CLI 本体不受影响。为什么写入必须在 WSL 里进行目录描述符围栏文档中“writes require WSL”一节的技术依据可以从仓库源码完整印证。能力探测supports_confined_dirfd()平台门禁的底层判断位于 claude_obsidian/paths.py 的supports_confined_dirfd()def supports_confined_dirfd() - bool: True when the POSIX openat-style confinement primitives all exist. return ( os.name ! nt and hasattr(os, O_DIRECTORY) and os.open in os.supports_dir_fd and os.mkdir in os.supports_dir_fd and os.rename in os.supports_dir_fd and os.stat in os.supports_dir_fd and os.unlink in os.supports_dir_fd )从源码结构看该函数要求 POSIX 的 openat 风格围栏原语全部齐备O_DIRECTORY标志、open/mkdir/rename/stat/unlink对dir_fd的支持且明确排除os.name nt。其 docstring 说明得很直白——原生 Windows 完全缺少O_DIRECTORY与dir_fd支持调用方在这些平台上走基于路径的降级分支而不是描述符围栏。写入门禁UNSUPPORTED_PLATFORM对 Vault 的一切变更操作写入前都会经过 claude_obsidian/transaction.py 中的_require_write_platform()该函数在任何副作用目录创建、备份暂存发生之前调用保证一次被拒绝的--apply不会留下任何残留它调用_require_lock_dirfd_support()探测能力若平台不满足则抛出专门的_PlatformConfinementUnavailableerrno.ENOTSUP再映射为TransactionValidationError(UNSUPPORTED_PLATFORM, ...)专用异常类型的设计用意在于Linux 上ENOTSUP与EOPNOTSUPP是两个不同的 errno 值如果混用平台门禁自身抛出的 ENOTSUP 可能会把“受支持宿主上真实文件系统返回的 EOPNOTSUPP”一并吞掉。面向用户的拒绝信息是transaction.pyvault writes require directory-descriptor confinement (WSL/Linux or supported macOS); on native Windows run this command inside WSL — read-only inspection and dry-runs work natively; if WSL itself misbehaves, see docs/windows-wsl.md同样的门禁也覆盖 capture 路径claude_obsidian/capture.py 在打开受围栏的.vault-meta/capture运行时目录时捕获_PlatformConfinementUnavailable抛出CaptureValidationError(UNSUPPORTED_PLATFORM, ...)——这解释了能力矩阵中“连只读的capture queue list也拒绝”的现象队列命令需要先把运行时目录 pin 住而这一步在无 dirfd 的原生 Windows 上无法完成。围栏到底防什么变更安全性被绑定到 POSIX 目录描述符整个写入期间vault 根目录与每个运行时目录都被“钉住”pinned在打开的目录描述符上后续mkdir/rename/unlink等一律通过dir_fd相对定位不跟随任何路径组件上的符号链接。因此一个并发被掉包的符号链接或被替换的文件夹不会把写入重定向到别处而会直接失败fail closed。配套的别名检查如CASEFOLD_PATH_ALIAS、UNSAFE_VAULT_IDENTITY的 parent pin 校验见 transaction.py进一步保证“你看到的 vault 名字”与“被锁住的那个 vault 对象”是同一个东西。原生 Windows 无法提供这些原语所以写入选择在入口处被明确拒绝而不是静默降级到更弱的保证。指南同时说明一个“降级写入模式”——默认关闭、由显式的“降低保证”开关控制——正在 issue #151 中讨论如果你被 WSL 卡住那是表达立场的地方。这条路径的验证覆盖位于 tests/test_windows_compat.py该测试在 POSIX 上通过禁用 dirfd 能力探测、移除os.O_DIRECTORY来模拟降级平台每个测试文件独立进程操作安全验证同一套降级分支的行为而真正的 Windows 行为CRT 文本模式O_BINARY、os.open拒绝打开目录、junction/reparse 语义、NTFS stat 身份等由真实的 windows-smoke CI 任务覆盖——文件头注释明确列出了模拟无法证明的部分这也是理解其证据边界的关键。WSL 排障症状、检查与清单“WSL 已安装”不等于“WSL 能正常工作”。下面先给出指南中的症状-检查对照表再给出建议按序执行的检查清单。症状对照表症状检查方法wsl --install完成了但wsl --status或wsl -l -v无限挂起该现场报告的挂起目前没有确认的根因。按 Microsoft 官方的 WSL 挂起诊断与上报流程处理见下文清单第 5 步。wsl报内核或版本错误依次执行wsl --update、wsl --shutdown然后重试。WSL 之前正常一次更新或软件变更之后停止工作不要先入为主归因。先更新 Windows 与 WSL再走 Microsoft 的 WSL 排障流程。原生 dry-run 得到的审批哈希在 WSL 里 apply 时失败报PLAN_CHANGED这是设计使然审批哈希绑定了审阅环境中的文件系统身份。如果 apply 将发生在 WSL 中就在 WSL 里跑被审阅的 dry-run原生环境产出的approved_plan_sha256无法在 WSL 中重放。写入失败UNSAFE_VAULT_IDENTITY提到稳定文件身份Vault 位于 FAT/exFAT 卷或不受支持的网络共享上。移到 NTFS或保留在 WSL 文件系统内部。关于PLAN_CHANGED的“按设计”源码层面的证据是变更锁获取阶段对“被审阅身份”的复核claude_obsidian/transaction.py 中MutationLock会用os.fstat(root_fd)取当前被 pin 住目录的设备号与 inode与审批计划中记录的expected_vault_identitydevice/inode逐一比对不一致即抛出PLAN_CHANGED“the selected vault object changed before locking”对尚不存在的 vault则比对父目录的parent_device/parent_inode与leaf。由于 NTFS 卷与 WSL 内的同一目录在两个环境里的设备/ inode 身份不同跨环境重放审批哈希必然失败——这不是 bug而是身份绑定的直接后果。排障检查清单按值得尝试的先后顺序从 Microsoft 官方 WSL troubleshooting 指南入手。确认 BIOS/UEFI 中已启用虚拟化并且“Virtual Machine Platform”与“Windows Subsystem for Linux”两个 Windows 功能均已启用启用任一功能后需重启。在提升权限的提示符中运行wsl --update然后wsl --shutdown再重试wsl --status。确认 hypervisor 启动设置已启用。如果安装了第三方 hypervisor使用支持 Hyper-V 的较新版本或在诊断冲突期间暂时关闭它。若 WSL 仍挂起按 Microsoft 官方的 WSL 挂起数据采集步骤收集诊断并提交给 WSL 项目。在没有诊断证据支持之前不要把挂起归因于某个具体原因。跨边界工作流原生审阅WSL 变更官方支持的跨边界工作流可以概括为一句话在原生 Windows 上检查与审阅在 WSL 内变更。由于审批哈希绑定产生它的环境被审阅的 dry-run 必须与执行 apply 的环境一致。如果变更将落在 WSL 里就在 WSL 里跑 dry-run、拿到审批哈希、再 apply反之亦然。Vault 放在 WSL 内部文件系统而不是挂载的 Windows 驱动器能同时规避两类问题上文“稳定文件身份”的坑以及跨边界访问的性能开销。原生 Windows 侧可用的能力inspect、dry-run 预览、retrieve可以照常用来做“读”的审阅所有“写”的动作留在 WSL 中完成。相关延伸阅读围栏与 pin 机制的完整设计见 复合 Vault 指南平台门禁与身份校验的其余实现细节可继续查看 claude_obsidian/transaction.py 与 claude_obsidian/capture.py。小结原生 Windows 的定位是只读 审阅inspect、dry-run、retrieval 可用写入类命令一律UNSUPPORTED_PLATFORM拒绝且拒绝发生在任何副作用之前。WSL 是全能力平台事务写入、capture 队列、模式设置等都在这里完成Git 检查点checkpoint则仅限 Linux/macOS。拒绝的根因在源码里清晰可见supports_confined_dirfd()的能力探测、_require_write_platform()的写入门禁、_require_stable_identity()对st_ino 0的UNSAFE_VAULT_IDENTITY校验。hooks 在 Windows 上“静默失效”的唯一原因是python3不在PATH上CLI 与 skills 不受影响排查时优先检查这一点。跨边界时牢记审批哈希绑定产生它的文件系统身份dry-run 与 apply 必须同环境Vault 留在 WSL 文件系统内部是最稳妥的布局。【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidian创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 claude-obsidian Windows 与 WSL 平台指南：只读原生、全能力 WSL 与排障实战
claude-obsidian Windows 与 WSL 平台指南只读原生、全能力 WSL 与排障实战【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidian本篇基于仓库中的 Windows/WSL 官方指南讲清楚 claude-obsidian 在 Windows 生态下的能力边界原生 Windows 是“只读平台”WSL 才是“全能力平台”。读完后你将掌握各平台能力矩阵、UNSUPPORTED_PLATFORM/UNSAFE_VAULT_IDENTITY/PLAN_CHANGED三类错误的源码级成因、Claude Code hooks 在 Windows 上依赖python3的机制以及一套可复用的 WSL 排障清单与跨边界工作流。平台能力矩阵哪些命令能在哪跑官方指南docs/windows-wsl.md给出的支持矩阵如下本文所有结论均以此为准能力WSL / Linux / macOS原生 Windows含 Git Bash检查、dry-run 预览、检索retrieval支持支持Vault 写入transaction apply、init、adopt、migrate、capture apply、mode set支持不支持 — 拒绝并报错UNSUPPORTED_PLATFORMCapture 队列命令包括只读的capture queue list支持不支持 — 当前一律拒绝上游已在 issue #151 跟踪Git 检查点checkpoint仅 Linux 和 macOS不支持Bash 安装脚本与 shell 测试套件支持不支持POSIX 专属Claude Code hooksSessionStart、Stop支持开箱即用部分支持要求python3在PATH上见下文也就是说在原生 Windows 上你可以放心做“看”的操作inspect、dry-run 预览、retrieve但所有“改”的操作都会被平台门禁platform gate在产生任何副作用之前直接拒绝WSL 里则是全功能。稳定文件身份是 Vault 的硬性前提除了操作系统本身的限制Vault 所在文件系统的“文件身份”稳定性也决定写入是否被放行NTFS 可以FAT/exFAT 卷典型如 U 盘和部分网络共享卷会被拒绝错误码为UNSAFE_VAULT_IDENTITY——解决办法是把 Vault 移到 NTFS 卷或放进 WSL 内部文件系统操作。从源码看这条拒绝来自 claude_obsidian/transaction.py 中的_require_stable_identity()当stat结果的st_ino为 0说明文件系统不暴露稳定的 inode 身份时抛出UNSAFE_VAULT_IDENTITY错误信息明确提示 “FAT/exFAT/some network shares; use an NTFS volume or WSL”。同一错误码还覆盖了“无法 pin 住 Vault 父目录”“无法枚举 Vault 父目录”等身份不可信的情形见 transaction.py 中的多处抛出点即任何一步无法确认“这个目录始终是这个目录”写入都会 fail closed。Claude Code hooks 与 Windows 上的 python3claude-obsidian 通过 hooks/hooks.json 注册了SessionStart与Stop两个 Claude Code 生命周期钩子配置形态如下exec-form 命令钩子{ type: command, command: python3, args: [ ${CLAUDE_PLUGIN_ROOT}/scripts/claude-obsidian.py, hook, session-start ], timeout: 5 }关键点在于command: python3加一个args数组Claude Code 会像可执行文件一样直接在PATH上解析python3并 spawn没有 shell 参与因此.batshim、shell alias 函数、shell profile 全部不会被参考。WSL 与大多数 Linux/macOS 的 Python 安装默认提供PATH上的python3所以那些环境下 hooks 无需额外配置即可工作。原生 Windows 常常没有常见有两种情形python.org 官方安装包装出来的是python.exe而不是python3.exe。对策有三种任选在解释器之前的PATH位置放一个python3.exeshim安装提供python3.exe的发行版或者干脆从 WSL 里运行 Claude Code让 hooks 解析到 WSL 的python3。Microsoft Store 版 Python其python3应用执行别名app execution alias可能只是一个会打开商店的 stub而不是真正的解释器。需要在 Windows 设置中禁用python3应用执行别名然后从 python.org 安装 Python 或在 WSL 中安装并确认真正的解释器在PATH上。还有一个值得注意的失败语义当python3无法被解析时Claude Code 根本起不了钩子进程claude-obsidian 自己的代码永远不会执行因而也无法输出任何诊断信息。此时SessionStart的上下文注入和Stop的恢复警告都会“安静地缺席”。但这只影响可选的 hook 路径——skills 与 CLI 本体不受影响。为什么写入必须在 WSL 里进行目录描述符围栏文档中“writes require WSL”一节的技术依据可以从仓库源码完整印证。能力探测supports_confined_dirfd()平台门禁的底层判断位于 claude_obsidian/paths.py 的supports_confined_dirfd()def supports_confined_dirfd() - bool: True when the POSIX openat-style confinement primitives all exist. return ( os.name ! nt and hasattr(os, O_DIRECTORY) and os.open in os.supports_dir_fd and os.mkdir in os.supports_dir_fd and os.rename in os.supports_dir_fd and os.stat in os.supports_dir_fd and os.unlink in os.supports_dir_fd )从源码结构看该函数要求 POSIX 的 openat 风格围栏原语全部齐备O_DIRECTORY标志、open/mkdir/rename/stat/unlink对dir_fd的支持且明确排除os.name nt。其 docstring 说明得很直白——原生 Windows 完全缺少O_DIRECTORY与dir_fd支持调用方在这些平台上走基于路径的降级分支而不是描述符围栏。写入门禁UNSUPPORTED_PLATFORM对 Vault 的一切变更操作写入前都会经过 claude_obsidian/transaction.py 中的_require_write_platform()该函数在任何副作用目录创建、备份暂存发生之前调用保证一次被拒绝的--apply不会留下任何残留它调用_require_lock_dirfd_support()探测能力若平台不满足则抛出专门的_PlatformConfinementUnavailableerrno.ENOTSUP再映射为TransactionValidationError(UNSUPPORTED_PLATFORM, ...)专用异常类型的设计用意在于Linux 上ENOTSUP与EOPNOTSUPP是两个不同的 errno 值如果混用平台门禁自身抛出的 ENOTSUP 可能会把“受支持宿主上真实文件系统返回的 EOPNOTSUPP”一并吞掉。面向用户的拒绝信息是transaction.pyvault writes require directory-descriptor confinement (WSL/Linux or supported macOS); on native Windows run this command inside WSL — read-only inspection and dry-runs work natively; if WSL itself misbehaves, see docs/windows-wsl.md同样的门禁也覆盖 capture 路径claude_obsidian/capture.py 在打开受围栏的.vault-meta/capture运行时目录时捕获_PlatformConfinementUnavailable抛出CaptureValidationError(UNSUPPORTED_PLATFORM, ...)——这解释了能力矩阵中“连只读的capture queue list也拒绝”的现象队列命令需要先把运行时目录 pin 住而这一步在无 dirfd 的原生 Windows 上无法完成。围栏到底防什么变更安全性被绑定到 POSIX 目录描述符整个写入期间vault 根目录与每个运行时目录都被“钉住”pinned在打开的目录描述符上后续mkdir/rename/unlink等一律通过dir_fd相对定位不跟随任何路径组件上的符号链接。因此一个并发被掉包的符号链接或被替换的文件夹不会把写入重定向到别处而会直接失败fail closed。配套的别名检查如CASEFOLD_PATH_ALIAS、UNSAFE_VAULT_IDENTITY的 parent pin 校验见 transaction.py进一步保证“你看到的 vault 名字”与“被锁住的那个 vault 对象”是同一个东西。原生 Windows 无法提供这些原语所以写入选择在入口处被明确拒绝而不是静默降级到更弱的保证。指南同时说明一个“降级写入模式”——默认关闭、由显式的“降低保证”开关控制——正在 issue #151 中讨论如果你被 WSL 卡住那是表达立场的地方。这条路径的验证覆盖位于 tests/test_windows_compat.py该测试在 POSIX 上通过禁用 dirfd 能力探测、移除os.O_DIRECTORY来模拟降级平台每个测试文件独立进程操作安全验证同一套降级分支的行为而真正的 Windows 行为CRT 文本模式O_BINARY、os.open拒绝打开目录、junction/reparse 语义、NTFS stat 身份等由真实的 windows-smoke CI 任务覆盖——文件头注释明确列出了模拟无法证明的部分这也是理解其证据边界的关键。WSL 排障症状、检查与清单“WSL 已安装”不等于“WSL 能正常工作”。下面先给出指南中的症状-检查对照表再给出建议按序执行的检查清单。症状对照表症状检查方法wsl --install完成了但wsl --status或wsl -l -v无限挂起该现场报告的挂起目前没有确认的根因。按 Microsoft 官方的 WSL 挂起诊断与上报流程处理见下文清单第 5 步。wsl报内核或版本错误依次执行wsl --update、wsl --shutdown然后重试。WSL 之前正常一次更新或软件变更之后停止工作不要先入为主归因。先更新 Windows 与 WSL再走 Microsoft 的 WSL 排障流程。原生 dry-run 得到的审批哈希在 WSL 里 apply 时失败报PLAN_CHANGED这是设计使然审批哈希绑定了审阅环境中的文件系统身份。如果 apply 将发生在 WSL 中就在 WSL 里跑被审阅的 dry-run原生环境产出的approved_plan_sha256无法在 WSL 中重放。写入失败UNSAFE_VAULT_IDENTITY提到稳定文件身份Vault 位于 FAT/exFAT 卷或不受支持的网络共享上。移到 NTFS或保留在 WSL 文件系统内部。关于PLAN_CHANGED的“按设计”源码层面的证据是变更锁获取阶段对“被审阅身份”的复核claude_obsidian/transaction.py 中MutationLock会用os.fstat(root_fd)取当前被 pin 住目录的设备号与 inode与审批计划中记录的expected_vault_identitydevice/inode逐一比对不一致即抛出PLAN_CHANGED“the selected vault object changed before locking”对尚不存在的 vault则比对父目录的parent_device/parent_inode与leaf。由于 NTFS 卷与 WSL 内的同一目录在两个环境里的设备/ inode 身份不同跨环境重放审批哈希必然失败——这不是 bug而是身份绑定的直接后果。排障检查清单按值得尝试的先后顺序从 Microsoft 官方 WSL troubleshooting 指南入手。确认 BIOS/UEFI 中已启用虚拟化并且“Virtual Machine Platform”与“Windows Subsystem for Linux”两个 Windows 功能均已启用启用任一功能后需重启。在提升权限的提示符中运行wsl --update然后wsl --shutdown再重试wsl --status。确认 hypervisor 启动设置已启用。如果安装了第三方 hypervisor使用支持 Hyper-V 的较新版本或在诊断冲突期间暂时关闭它。若 WSL 仍挂起按 Microsoft 官方的 WSL 挂起数据采集步骤收集诊断并提交给 WSL 项目。在没有诊断证据支持之前不要把挂起归因于某个具体原因。跨边界工作流原生审阅WSL 变更官方支持的跨边界工作流可以概括为一句话在原生 Windows 上检查与审阅在 WSL 内变更。由于审批哈希绑定产生它的环境被审阅的 dry-run 必须与执行 apply 的环境一致。如果变更将落在 WSL 里就在 WSL 里跑 dry-run、拿到审批哈希、再 apply反之亦然。Vault 放在 WSL 内部文件系统而不是挂载的 Windows 驱动器能同时规避两类问题上文“稳定文件身份”的坑以及跨边界访问的性能开销。原生 Windows 侧可用的能力inspect、dry-run 预览、retrieve可以照常用来做“读”的审阅所有“写”的动作留在 WSL 中完成。相关延伸阅读围栏与 pin 机制的完整设计见 复合 Vault 指南平台门禁与身份校验的其余实现细节可继续查看 claude_obsidian/transaction.py 与 claude_obsidian/capture.py。小结原生 Windows 的定位是只读 审阅inspect、dry-run、retrieval 可用写入类命令一律UNSUPPORTED_PLATFORM拒绝且拒绝发生在任何副作用之前。WSL 是全能力平台事务写入、capture 队列、模式设置等都在这里完成Git 检查点checkpoint则仅限 Linux/macOS。拒绝的根因在源码里清晰可见supports_confined_dirfd()的能力探测、_require_write_platform()的写入门禁、_require_stable_identity()对st_ino 0的UNSAFE_VAULT_IDENTITY校验。hooks 在 Windows 上“静默失效”的唯一原因是python3不在PATH上CLI 与 skills 不受影响排查时优先检查这一点。跨边界时牢记审批哈希绑定产生它的文件系统身份dry-run 与 apply 必须同环境Vault 留在 WSL 文件系统内部是最稳妥的布局。【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidian创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考