Claudian Brings Claude Code Into Obsidian — Which Makes Your Notes a Workspace, Not Just Context

Claudian Brings Claude Code Into Obsidian — Which Makes Your Notes a Workspace, Not Just Context

Putting Claude Code inside Obsidian sounds like a convenience feature until you follow the permissions. Then it becomes something more consequential: your notes are no longer just context. They are a workspace an agent can read, search, edit, diff, compact, augment with MCP, and operate from with shell access. That is powerful. It is also the kind of boundary collapse that deserves more than plugin-store optimism.

Claudian shipped 2.0.21 on June 1, patching SDK import metadata for Obsidian and carrying forward a same-day dependency-security fix from 2.0.20. Earlier the same day, 2.0.19 restored Mod+Enter composer send, added Pi provider integration, rendered markdown in inline edit previews, guarded OpenCode hydration against large metadata, and added Claude custom model aliases. None of that is a splashy launch. All of it is the work of keeping a serious agent surface alive inside a desktop knowledge app.

The numbers suggest people are using it. At research time the repository had 12,164 stars, 739 forks, 68 open issues, and thousands of release-asset downloads: 2,083 for manifest.json, 1,689 for main.js, and 1,661 for styles.css. Claudian requires Obsidian 1.7.2 or newer, desktop only, with Claude Code CLI for the Claude provider and optional Codex CLI, OpenCode, and Pi integrations.

The feature list reads like a coding-agent IDE grafted into a vault: file read/write, search, bash, multi-step workflows, inline edits with word-level diff preview, slash commands and skills at user and vault scopes, @mention for files, subagents, MCP servers and external directories, Plan Mode through Shift+Tab, custom instructions, MCP over stdio/SSE/HTTP, multi-tab conversations, fork/resume/compact, and provider-specific session storage. The README’s key sentence is blunt: the vault becomes the agent’s working directory.

Your vault is now a repo with feelings

That is the useful mental model. Obsidian vaults often contain specs, design notes, meeting records, research clips, product plans, API sketches, todo lists, private journals, customer fragments, copied credentials, and the kind of half-formed strategy notes people would never intentionally upload to a model provider. Developers already treat repos as sensitive. They do not always treat notes that way, even when the notes contain more business context than the repo.

Claudian’s privacy section is unusually clear, and that transparency should be taken seriously. User input, attached files, images, and tool-call outputs go to the configured provider. Settings and session metadata live in vault/.claudian/. Claude provider files live in vault/.claude/. Transcripts live in provider-specific session directories. Provider subprocesses inherit the Obsidian environment plus configured variables. If MCP endpoints are connected, the agent can reach those too.

None of that makes Claudian bad. It makes it developer tooling. A plugin that can read and write your vault, invoke provider CLIs, inherit environment variables, and talk to MCP servers belongs in the same risk category as a local coding agent, not a theme pack. The correct installation ritual is not “click install, ask it about your diary.” It is: choose the vault, inspect what is inside, decide which provider can see it, review environment variables, start with Plan Mode, and use inline diffs before writes.

The productive side is real. Engineering intent already lives in notes. Architecture decisions, incident timelines, customer requirements, launch plans, research summaries, API tradeoffs — these are exactly the artifacts a coding agent needs but often cannot see. Pulling an agent into Obsidian can reduce the gap between “what the team decided” and “what the agent edits.” A solo builder can ask the agent to update a decision log, inspect related project notes, draft implementation tasks, and generate code-adjacent artifacts without leaving the vault. That is a coherent workflow.

One workspace, many agent engines, many different semantics

The provider pluralism is the other interesting story. Claudian supports Claude Code, Codex, OpenCode, and Pi. That mirrors the broader agent market: users want one workspace and multiple engines. Claude may be better for one workflow, Codex for another, OpenCode for a local/open harness, Pi for a different interaction style. The workspace becomes stable; the agent backend becomes swappable.

Swappable does not mean equivalent. Approval semantics, context handling, compaction behavior, MCP behavior, tool-call reliability, and transcript storage differ by provider. The release note about guarding OpenCode hydration against large metadata is a useful reminder: provider integration bugs are not theoretical. If a vault is the working directory, an integration bug can affect project state, not just chat quality.

Teams considering Claudian should separate experimental and sensitive vaults. A project vault with sanitized specs and design docs is a reasonable place to start. A personal vault with finance notes, health records, unredacted customer details, and production credentials is not. If the plugin is used in a company context, write policy for vault scopes, provider choices, MCP servers, transcript retention, and whether vault-level skills can execute against private notes. This sounds heavy until the first agent reads a confidential acquisition memo because it was linked from a project plan.

There is also a positive governance pattern here. Obsidian can become a human-readable control plane for agent work: plans, decisions, prompts, task histories, review notes, and final reports can live beside the source-of-truth context. That is better than scattering agent state across terminal scrollback and provider dashboards. But the workspace needs boundaries. Notes are not magically safe because they are markdown.

For individual practitioners, the checklist is straightforward. Start in a disposable vault. Confirm where transcripts are written. Remove sensitive environment variables before launching provider subprocesses. Prefer provider-specific API keys with limited scope. Use Plan Mode for multi-step work. Review inline diffs. Keep MCP servers explicit and minimal. If you would not let a shell script recurse through the vault and send selected content to a remote API, do not let an agent do the same thing without understanding the path.

The editorial take: Claudian is a serious signal that personal knowledge bases are becoming executable agent workspaces. That is a good product direction. It puts the agent where the intent lives. But it also means the humble notes vault now needs repo-grade hygiene: scope, secrets discipline, provider policy, transcript awareness, and review before mutation. LGTM — with guardrails, not incense.

Sources: Claudian GitHub repository, Claudian 2.0.21 release, Obsidian community plugin page, Claude Code overview