# WeSight for Obsidian runs your own agent CLI, and stops short of publishing for you

> An Obsidian plugin that puts Claude Code, Codex or OpenCode in a sidebar chat inside your vault, turns a note into platform drafts through a localhost handoff to a browser extension, and gates a Knowledge Brain workflow behind a signed entitlement and a pinned, checksummed runtime download.

**freestylefly/wesight-obsidian** — WeSight Obsidian plugin for local agent runtimes.

- Repository: https://github.com/freestylefly/wesight-obsidian
- Website: https://wesight.ai/
- Stars: 408 · Forks: 72
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/freestylefly-wesight-obsidian

## It runs the CLI as a child process and refuses to install it

The requirements are stated as preconditions rather than steps. Obsidian 1.11.4 or later on desktop. At least one supported agent CLI installed independently, and three are named: Claude Code, Codex and OpenCode. The Feishu workflow is optional and needs a separately installed Lark CLI. WeChat theme generation uses a bundled gzh-design Skill, though a compatible local installation can override the bundled copy for development.

Detection follows from that stance. WeSight looks for existing executables in the configured path, the system path, and compatible legacy WeSight runtime locations, and states plainly that it does not install or update CLI tools, agent runtimes or their dependencies. If a CLI is missing, the plugin cannot fix it.

Setting it up is four steps: pick Claude Code, Codex or OpenCode under Settings and WeSight, confirm the CLI was detected or type its executable path yourself, open the sidebar from the ribbon or the command palette, then chat. You can mention vault files, attach or paste images, switch models and use slash commands.

The consequence of the child-process model is worth stating plainly, because it governs everything else. Agent capabilities, provider requests, tool calls, file access and approval behaviour all follow that CLI's own configuration. WeSight is the surface, not the policy.

The 1.2.1 patch was a visible bug rather than a feature: it fixes duplicated Claude Code replies and duplicated thinking content while preserving live streaming.

Chat images take a clear path. Input is accepted as PNG, JPEG, WebP or GIF up to 25 MB each, and a selected image is copied into the current vault, shown alongside the conversation, and handed to the selected CLI as a local attachment. Whether those bytes leave the device is then decided by that CLI and whatever provider it is configured against.

## Publishing stops at an editable draft, handed over on 127.0.0.1

The multi-platform path is labelled 分享 then 多平台, and it covers Zhihu, CSDN, Juejin, Bilibili articles, Toutiao and Weibo articles. The social workbench adds Xiaohongshu image posts, Weibo image posts and Jike posts on top of that list.

The transfer mechanism is a browser extension rather than an API client. You install WeSight Publish Assistant 1.0.0 or later in Chrome, Edge or Arc and complete a one-time local pairing. The plugin then 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 go through WeSight Cloud.

What the extension does with the payload is where the design choice sits. It uploads to the platforms you selected using the browser's existing signed-in session, which is why a login can expire mid-run, and why the task panel offers status, editor links, login recovery and retries. Obsidian has to stay open until preparation finishes.

Every workflow ends at an editable draft and stops there. The final Publish action is performed by you. The existing WeChat draft service continues to run separately from this path.

## 转为图文 opens a side workbench and leaves the note where it is

The article-to-social entry point appears in the WeSight header, the note toolbar, the file menu and the command palette. Activating 转为图文 opens a workbench on the right side while the original note stays visible on the left, so the source text remains in view during editing.

快速转 is the fast path: it prepares Xiaohongshu, Weibo image posts and Jike posts, with copy that is either shared across platforms or specific to one. From there you review the copy in place, select and reorder the images taken from the original article, or open a platform tab for more detailed editing.

The Xiaohongshu image workspace splits into two halves, and they have different privacy properties. One holds local typography templates. The other is a separate AI-image gallery offering style selection, reference images, aspect ratios, single-image regeneration and ordering.

That gallery has a dependency you should notice before planning around it. Generation uses your configured compatible agent and provider, AI image generation requires image-generation support on that side, and inputs may be sent to that provider according to its own configuration. WeSight does not generate the images itself.

Local drafts and generated assets are written under `.wesight/` inside the vault, so they sit alongside your notes rather than in an application directory. That also means the folder is something a sync service or a backup will carry, which is convenient until you count how many generated images accumulate there.

## One platform at a time on the free tier, and the notice appears on the second pick

The publishing limits are specific enough to plan around. Signed-in free users can convert and prepare one platform at a time. Active members can select multiple platforms.

What happens when a free user reaches for a second platform is described in detail: an inline membership notice appears, and the edited text and images are not lost. That is the part that matters in practice, because a paywall that discards work pushes people to keep several parallel drafts outside the tool.

Initial entry has no membership prompt, so nothing is announced before you have already put effort into a conversion.

The same split appears elsewhere in the product. OpenLux model groups, added in 1.2.0, are grouped by manufacturer in settings and in the two-column chat picker, with search and collapsible groups. Member models and usage, added in 1.1.0, show the remaining weekly allowance next to the usage entry in the account menu and open a web dashboard with model usage and reset times. Existing installations keep the configuration they selected, while model availability follows whatever entitlement the account currently has.

## Model access splits between a member entitlement and connections you own

There are two routes to a model in this plugin, and they behave differently over time.

The member route is WeSight member models reached through the recommended configuration, or a personal TokenDance connection. This is the part that is tied to an account: the dashboard reports weekly allowance and reset times, and availability follows the current entitlement rather than anything you configured. Existing installations retain the configuration they already selected, so upgrading does not silently repoint you, but losing entitlement does silently remove models.

The OpenLux route, added in 1.2.0, is a Claude Code feature and sits immediately after TokenDance in the list. You enter an API key, fetch your account's chat models, and choose a default. Those models are then grouped by manufacturer in both settings and the chat picker, with search and collapsible groups. The setup, compatibility and validation detail for that release was moved into its own file under `docs/releases/`, and the same pattern holds for 1.1.0 and 1.2.1, so the README carries the summary and the documents carry the specifics.

The split matters for a vault you care about. Member models carry a quota and a reset clock; an OpenLux connection carries an API key you supplied. Nothing in the plugin reconciles the two, so a workflow written against one will fail in a predictable way when you switch to the other.

## Knowledge Brain pins a commit and a SHA-256 before it runs anything

Knowledge Brain is an opt-in local knowledge workflow powered by the claude-obsidian project, available as a member-only internal test and explicitly not consuming WeSight credits. The first release covers local macOS vaults, Python 3.11 or later, and Claude Code or Codex.

Access is gated by a signed entitlement requested from `api.wesight.ai` after WeSight sign-in. Active Creator members receive a token valid for at most seven days and never past the membership expiry date. A valid cached token keeps the local workflow available during a temporary network outage, so the gate is about entitlement rather than connectivity. When membership access ends, new enable, collection, query, answer-save and preview-apply operations lock, while health checks, interrupted-transaction recovery and existing local files stay available.

Enabling it downloads a pinned claude-obsidian 2.1.0 archive at commit `a3b3df4539802e150e942266fd310c1b5978a3c0`. Downloads are accepted only from `github.com` and its `codeload.github.com` redirect, extraction is bounded, the SHA-256 is checked against `7c52eab5655da9735ef29903de3b1294e9d69c7b9fdb70b28aa7676dc3156870`, the package and contracts are validated, and the result installs under `~/.wesight/knowledge-brain/runtimes/claude-obsidian/2.1.0/`.

For a workflow that reads and writes your notes, that chain of checks is the part to read carefully rather than skim.

## Vault adoption is a reviewed dry run, and a query runs in its own session

Two safety properties are described for the write path. Vault adoption uses the exact reviewed dry-run parameters and creates only the paths listed by that plan, with existing note bytes left unchanged. Collection and answer saving go through a read-only planning turn, then deterministic transaction validation, then a user-facing preview, then explicit confirmation.

Reads are separated from writes in a way that is easy to miss. Knowledge queries run in a separate read-only session, and Obsidian wikilinks are verified before an answer is displayed, so a query cannot quietly mutate the vault while it retrieves.

Only part of the command surface is visible. Two commands are described: one that validates prerequisites and adopts the current vault, and one that plans and previews the active Markdown note. A third, for asking a question, is cut off after its opening words, so its full description is not available here.

Given that the runtime is pinned to one commit and the write path goes through a preview, the sensible first move is the adoption command on a vault you can restore, and reading the plan before confirming it.

## package.json declares AGPL and builds with tsc before esbuild

The manifest names the package wesight-obsidian at version 1.2.1, marks itself an ES module with `main.js` as the entry point, and declares its license as AGPL-3.0-or-later. A `LICENSE` file, a `LICENSES/` directory and `THIRD_PARTY_NOTICES.md` sit at the top level alongside `THIRD_PARTY_NOTICES.md`, which is the arrangement you would expect from a plugin that vendors third-party code. A `vendor/` directory is present too.

The script set is small and the order of the aggregate one is informative. `dev` runs esbuild in watch mode. `build` runs `tsc --noEmit` before the production esbuild pass, so type errors fail the build rather than the editor. `test` is `vitest run`, `lint` is `eslint .`, and `verify:release` is a separate node script. `check` chains them: test, then lint, then build, then verify release.

Runtime dependencies are three packages: `qrcode`, `@codemirror/state` and `@codemirror/view`, which together account for the QR pairing flow and the inline editing surface. Development dependencies pin vitest at ^4.0.14, typescript at ^5.9.3 and eslint at ^9.39.1, with `eslint-plugin-obsidianmd` alongside.

One mismatch is worth knowing about: the dev dependency on `obsidian` is declared as ^1.8.7 while the stated runtime floor is Obsidian 1.11.4 on desktop. Type checking therefore targets API typings older than the version the plugin asks you to run.

The remaining top-level files explain how the release is put together. `manifest.json` and `versions.json` carry what Obsidian reads to offer an update, `esbuild.config.mjs` and `vitest.config.ts` drive the build and the tests, `styles.css` carries the pane styling, and `assets/` holds what the interface references. A `.github/` directory and a `scripts/` directory holding the release verification script sit alongside them.

## Conclusion

Use it if you already have an agent CLI installed and want it attached to your notes rather than to a chat window, since the plugin refuses to install or manage those tools itself. Expect a membership wall on multi-platform publishing and on the Knowledge Brain, and read that as part of the design rather than a trial expiring. Before you rely on the publish flow, check what your own agent CLI does with attached images, because the plugin copies them into the vault and hands them to whatever CLI and provider you selected, and those decide whether the bytes leave your device.

## FAQ

### What does WeSight for Obsidian need installed before it will work?

Obsidian 1.11.4 or later on desktop, plus at least one agent CLI installed on its own: Claude Code, Codex or OpenCode. The Feishu workflow additionally needs a separately installed Lark CLI, and WeSight does not install or update any of these.

### Does WeSight publish posts to Chinese platforms automatically?

No. Every workflow stops at an editable draft and you perform the final Publish action. A Chrome extension named WeSight Publish Assistant uploads using your browser's existing signed-in session, reached over a temporary HTTP service bound only to 127.0.0.1.

### Where does the WeSight Obsidian plugin store drafts and generated images?

Local drafts and generated assets are stored under `.wesight/` inside the vault. AI image generation in the Xiaohongshu workspace is not done locally by the plugin; it runs through your configured compatible agent and provider, and inputs may be sent to that provider according to its configuration.

### How is the Knowledge Brain feature gated and how is its runtime downloaded?

It requests a signed entitlement from api.wesight.ai after sign-in, and Active Creator members get a token valid for at most seven days. Enabling it downloads a pinned claude-obsidian 2.1.0 archive at a named commit, verifies a specific SHA-256, and installs under ~/.wesight/knowledge-brain/runtimes/claude-obsidian/2.1.0/.

### What limits apply to free WeSight Obsidian users preparing platform posts?

Signed-in free users can convert and prepare one platform at a time, while active members can select multiple. Attempting a second free-user selection shows an inline membership notice without losing edited text or images, and initial entry shows no membership prompt.

## Sources

- [freestylefly/wesight-obsidian on GitHub](https://github.com/freestylefly/wesight-obsidian)
- [Issues](https://github.com/freestylefly/wesight-obsidian/issues)
- [Project website](https://wesight.ai/)
- [README](https://github.com/freestylefly/wesight-obsidian/blob/main/README.md)
- [Releases](https://github.com/freestylefly/wesight-obsidian/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/freestylefly-wesight-obsidian