WeSight for Obsidian: run Claude Code, Codex, and OpenCode inside a vault
WeSight Obsidian plugin for local agent runtimes.
At a glance
- What is it?
- WeSight is an Obsidian plugin that drives local agent CLIs as child processes and adds an article-to-social workbench. It is desktop-only, it does not install the CLIs for you, and its publishing flow stops at a draft you publish yourself.
- Who is it for?
- Adopt WeSight if you already run Claude Code, Codex, or OpenCode from a terminal, keep your notes in a desktop Obsidian vault, and want the agent to see vault files without copying paths by hand. Skip it if you work on mobile, if you want the plugin to manage CLI installation and updates (the README states it does not), or if you need a fully offline pipeline: image input and AI image generation go to whichever provider your CLI is configured with.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What WeSight adds to a vault that already has an agent CLI
The plugin does not ship a model or a runtime. It is a front end for Claude Code, Codex, or OpenCode, which the README lists as a hard requirement: at least one of those CLIs must be installed independently. The problem it addresses is context. An agent running in a terminal sees the working directory you launched it from; WeSight runs the selected CLI as a child process and gives it the vault, so you can mention notes, attach images, and apply edits without leaving Obsidian. The audience is narrow on purpose: desktop Obsidian users who already pay for or configure one of those three CLIs and want their notes in the loop. If you do not already run one of them, this plugin has nothing to drive.
How the local agent chat actually runs
The mechanism is process spawning, not an API client. Per the README, local chats and inline edits run the selected CLI as a child process, and agent capabilities, provider requests, tool calls, file access, and approval behavior follow that CLI's own configuration. That single sentence carries most of the design. WeSight does not reimplement tool permissions or approval prompts; whatever your CLI does about file writes is what happens inside the vault. Settings hold the choice of CLI and an executable path, and detection checks the configured path, the system path, and compatible legacy WeSight runtime locations. Chat image input accepts PNG, JPEG, WebP, and GIF up to 25 MB each; selected images are copied into the current vault, shown with the conversation, and passed to the CLI as local attachments. The README is explicit that the CLI and its provider decide whether those bytes leave the device, which is a fair warning rather than a guarantee. Inline editing follows the same path: select text, run WeSight: Inline edit, and review the proposed replacement before applying it.
Installing the plugin and getting one answer out of a note
The README does not give a plugin install command, so treat the CLI as the prerequisite and get it working first. Confirm the CLI runs on its own, then install WeSight in Obsidian and open its settings. The README's numbered flow is the only setup sequence it documents: open Settings then WeSight and select Claude Code, Codex, or OpenCode; confirm that WeSight detects the CLI, or enter its executable path; open the WeSight sidebar from the ribbon or command palette; then chat with the selected agent, mention vault files, attach or paste images, switch models, or use slash commands.
npm run buildThe package.json defines this script as tsc --noEmit followed by node esbuild.config.mjs production, which is how the plugin is built from source if you are working from the repository rather than an installed copy. It produces the plugin bundle; it does not build or install the agent CLI.
npm run checkThis chains npm test, npm run lint, npm run build, and npm run verify:release, which is the project's own gate before a release. For a first real use, follow the README: mention a vault file in the sidebar prompt to pull it into context, or select text in a Markdown note and run the inline edit command, then review the proposed replacement before applying it. The first thing you should see is the sidebar conversation responding; if it does not, the executable path is the first thing to check, since the plugin does not install or update CLI tools, agent runtimes, or their dependencies.
The article-to-social workbench and where it stops
Version 1.0.0 adds a second job: turning a note into platform drafts. 转为图文 opens a right-side workbench while the original note stays visible, and 快速转 prepares Xiaohongshu, Weibo image posts, and Jike posts with shared or platform-specific copy. The Xiaohongshu image workspace offers local typography templates plus an AI-image gallery with style selection, reference images, aspect ratios, single-image regeneration, and ordering. Generation uses your configured agent or provider, and AI image generation requires image-generation support, so the feature inherits whatever model you already wired up. Local drafts and generated assets live under .wesight/ in the vault. Browser-assisted drafts cover Zhihu, CSDN, Juejin, Bilibili articles, Toutiao, and Weibo articles, and require the separate WeSight Publish Assistant extension in Chrome or Edge plus a one-time local pairing flow. The plugin starts a temporary HTTP service bound only to 127.0.0.1, and task access expires after ten minutes. Article and image transfer to the extension does not use WeSight Cloud, but the extension then uploads through the browser's existing signed-in session. The boundary matters: every workflow stops at an editable draft, and the README states that you perform the final Publish action. This is not a scheduler, and it is not unattended publishing.
Membership gates, Knowledge Brain, and the free-tier limit
Two features are gated. Signed-in free users can convert and prepare one platform at a time; active members can select multiple platforms. Attempting a second free-user selection shows an inline membership notice without losing edited text or images, and initial entry has no membership prompt. Knowledge Brain is stricter: an opt-in local knowledge workflow powered by claude-obsidian, described as a member-only internal test that does not consume WeSight credits. The first release supports local macOS vaults, Python 3.11 or later, and Claude Code or Codex. The plugin requests a signed entitlement from api.wesight.ai after sign-in, and active Creator members receive a token valid for at most seven days and no later than the membership expiry. A valid cached token keeps the workflow available during a temporary network outage; when membership access ends, new enable, collection, query, answer-save, and preview-apply operations are locked, while health checks, interrupted-transaction recovery, and existing local files remain available. Enabling it downloads a pinned claude-obsidian 2.1.0 archive at commit a3b3df4539802e150e942266fd310c1b5978a3c0, accepts downloads from github.com and its codeload.github.com redirect, enforces bounded archive extraction, verifies SHA-256 7c52eab5655da9735ef29903de3b1294e9d69c7b9fdb70b28aa7676dc3156870, validates the package and contracts, and installs under ~/.wesight/knowledge-brain/runtimes/claude-obsidian/2.1.0/. The five commands are Chinese-labeled: 开启知识大脑, 收录当前笔记到知识大脑, 向知识大脑提问, 保存最近 AI 回答到知识大脑, and 知识大脑健康检查. Vault adoption uses the exact reviewed dry-run parameters and only creates paths listed by that plan, and existing note bytes remain unchanged. Interrupted transactions pause new collection and saving until you confirm a separate recovery action.
Where WeSight is the wrong tool
Desktop only, and the README sets the floor at Obsidian 1.11.4 or later. Mobile is out. So is any setup where you expect the plugin to manage your toolchain: it detects executables but does not install or update CLI tools, agent runtimes, or their dependencies, and the optional Feishu workflow needs an independently installed Lark CLI. The browser-assisted path has its own constraints. It requires the WeSight Publish Assistant extension at version 1.0.0 or later, the temporary HTTP service is bound to 127.0.0.1 with task access expiring after ten minutes, and you must keep Obsidian open until preparation completes. If your workflow is "write, close the laptop, publish later," that ten-minute window and the open-app requirement will bite. Two more honest limits: image bytes go to whichever provider the CLI is configured with, so the plugin cannot promise local-only processing, and the README's sharing section states that frontmatter, embedded notes, and Mermaid source remain local, with the sharing panel displaying warnings before publishing omitted content. Wiki links become visible text in published snapshots, which is a lossy conversion for anyone who relies on them.
How it compares with driving the CLI from a terminal
The real alternative is not another Obsidian plugin; it is running Claude Code, Codex, or OpenCode in a terminal with the vault as the working directory. That approach has no membership tiers, no 25 MB image ceiling, no ten-minute pairing window, and no dependency on Obsidian 1.11.4. It also has no sidebar conversation attached to the note you are reading, no inline edit command that proposes a replacement in place, no file mentions, and no workbench that turns a finished article into platform drafts under .wesight/. The difference is not capability but adjacency: WeSight's value is that the agent and the note live in the same window. If you already keep a terminal open beside Obsidian and do not write for the platforms the workbench targets, the plugin adds a dependency layer without changing what the CLI can do. The CLI still owns approvals and tool calls either way.
Licence and upgrade cost
The repository's LICENSE file is present alongside a LICENSES/ directory and THIRD_PARTY_NOTICES.md, while package.json declares AGPL-3.0-or-later. The GitHub metadata reports the licence as NOASSERTION, so the two signals do not agree, and anyone embedding this plugin in a distributed product should read LICENSE and LICENSES/ directly rather than trusting a single field. This is not legal advice. On upgrades, the version history shows a fast cadence around the 1.0.0 release, and the README points to docs/releases/1.0.0.md for the complete Chinese update summary and upgrade instructions, which suggests reading the release notes before updating rather than assuming compatibility. The build pipeline is conventional for an Obsidian plugin: npm run build runs tsc --noEmit and an esbuild production pass, and npm run check chains tests, lint, build, and verify:release. Knowledge Brain pins its runtime to a specific commit and SHA-256 hash, so that component upgrades only when the plugin ships a new pin, not on your schedule. The last push to the repository was on 2026-09-10, and the repository is not archived.
Editorial conclusion
Adopt WeSight if you already run Claude Code, Codex, or OpenCode from a terminal, keep your notes in a desktop Obsidian vault, and want the agent to see vault files without copying paths by hand. Skip it if you work on mobile, if you want the plugin to manage CLI installation and updates (the README states it does not), or if you need a fully offline pipeline: image input and AI image generation go to whichever provider your CLI is configured with. Before committing, confirm that Obsidian 1.11.4 or later is installed, that WeSight detects your CLI executable in Settings, and that the AGPL-3.0-or-later terms in package.json fit how you distribute your vault tooling.
Frequently asked questions
Does WeSight for Obsidian install Claude Code, Codex, or OpenCode for me?
No. At least one supported agent CLI must be installed independently, and the README states that WeSight does not install or update CLI tools, agent runtimes, or their dependencies. It only detects existing executables from the configured path, the system path, and compatible legacy WeSight runtime locations.
What do I need before using the browser-assisted platform drafts?
Install WeSight Publish Assistant 1.0.0 or later in Chrome or Edge and complete the one-time local pairing flow. The plugin starts a temporary HTTP service bound only to 127.0.0.1, task access expires after ten minutes, and you keep Obsidian open until preparation completes. Every workflow stops at an editable draft, and you perform the final Publish action.
Can free users prepare drafts for more than one platform at a time?
No. Signed-in free users can convert and prepare one platform at a time, while active members can select multiple platforms. Attempting a second free-user selection shows an inline membership notice without losing edited text or images, and initial entry has no membership prompt.
Community notes