Claude Sidebar Puts an Agent CLI Inside Obsidian, With Python in the Middle
Run Claude Code, Codex, and other agent CLIs in Obsidian
At a glance
- What is it?
- The plugin embeds a real pseudo-terminal in Obsidian's sidebar so Claude Code, Codex and eight other agent CLIs run where your notes live. The architecture is a JavaScript front end driving base64-embedded Python PTY scripts, and that choice explains most of its setup friction.
- Who is it for?
- Adopt Claude Sidebar if you already run an agent CLI in a terminal and want it anchored to a vault or an external project directory, and you are willing to keep Python 3 plus pywinpty current on Windows. Skip it if you need a mobile client (the README points to a separate project, Claude Anywhere) or if you would rather not run an agent with write access inside your notes.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Claude Sidebar fills is context switching, not capability
The agent CLI is already good at reading and editing files. What it does not have is your vault. Claude Sidebar closes that gap by putting the CLI's terminal inside Obsidian's sidebar, so the agent runs with the vault as its working directory instead of a directory you typed into a shell. The README frames the plugin around exactly this: right-click a folder for "Open here," right-click a file to send its path to the agent, or run "Run agent from this folder" to start in the active file's directory.
The intended user is someone who takes notes in Obsidian and codes or writes with an agent CLI in the same session. It is not a chat panel bolted onto a note. It is a terminal, and the README says so: "Full terminal with an agent in your Obsidian sidebar." That distinction matters, because it means the plugin inherits the terminal's affordances (multi-line input via Shift+Enter, resuming with --continue) and its hazards. Folder and file targeting plus YOLO mode means an agent can be pointed at a directory and left to act. The plugin gives you the aiming mechanism; it does not add a confirmation layer of its own.
xterm.js on top, a Python pseudo-terminal underneath, glued by base64
The mechanism is a three-part stack. xterm.js handles terminal emulation in the Obsidian pane. A Python script owns the pseudo-terminal: terminal_pty.py on Unix, terminal_win.py on Windows, using the standard library pty module on macOS and Linux and pywinpty on Windows. main.js is the plugin shell that ties the two together.
The unusual part is packaging. The README states that both PTY scripts "are embedded as base64 in main.js for Obsidian plugin directory compatibility." Obsidian plugins ship as a small set of files, so the Python processes are carried inside the JavaScript bundle and written out or invoked from there rather than living as loose scripts next to the plugin. The consequence for anyone modifying the project is direct: editing terminal_pty.py or terminal_win.py does nothing until you run ./build.sh to regenerate main.js. That is a build step most Obsidian plugin users never think about, and it is the first thing a contributor will trip over.
Data flow is conventional for a terminal: the CLI process writes to the PTY, the Python layer relays bytes to the plugin, xterm.js renders them, and keystrokes travel back the same way. Everything the agent prints is terminal output, not parsed structured data. The plugin's intelligence lives in how it launches and targets processes, not in interpreting what they say.
Installing it, and the Windows path that needs more than a click
The recommended route is the community plugin listing: visit community.obsidian.md/plugins/claude-sidebar, click Add to Obsidian, then Install and Enable. Manual installation drops three release artifacts into the vault:
mkdir -p .obsidian/plugins/claude-sidebar && cd .obsidian/plugins/claude-sidebar && curl -LO https://github.com/derek-larson14/obsidian-claude-sidebar/releases/latest/download/main.js && curl -LO https://github.com/derek-larson14/obsidian-claude-sidebar/releases/latest/download/manifest.json && curl -LO https://github.com/derek-larson14/obsidian-claude-sidebar/releases/latest/download/styles.css
Updating manually is the same three curl calls from inside the plugin directory, followed by a restart or a disable/enable cycle. Requirements are Python 3 and an agent CLI, with Claude Code as the default backend.
Windows is where setup stops being one click. After installing, the README instructs you to install pywinpty into the Python the plugin will use, and to run it as py -m pip install pywinpty rather than plain pip, because plain pip may target a different interpreter. If the sidebar reports "pywinpty not installed," the error prints the exact interpreter path, and you install into that one. Then you choose a shell in Settings, Claude Sidebar, Shell: cmd.exe by default, or wsl.exe. The WSL option translates vault paths to Linux form via wslpath, and the README notes that translation respects a custom /etc/wsl.conf automount root, so paths still resolve when C: mounts at /c/ instead of /mnt/c. Linux and macOS always run bash; the shell setting is Windows-only.
Ten backends behind one setting, and what switching actually changes
The plugin lists Claude Code, Codex, Grok Build, OpenCode, Antigravity CLI, Kimi Code, GitHub Copilot, Cursor Agent, and Pi as selectable backends. Settings holds the default; the command palette offers "Switch default CLI provider…" to change what every new tab uses, and "New agent tab (other CLI)…" for a one-off tab on a different CLI without changing the default. Multiple tabs can run side by side.
The design separates the default from the exception, which is the right shape for a tool where most sessions use one CLI but occasional tasks want another. What the README does not describe is how much of the plugin's behaviour is backend-specific. Context actions (send file path, send selection, drag-drop, image paste, wikilink references) are described in general terms, and the Windows path-translation list enumerates them together, implying they are handled at the plugin layer rather than per CLI. Resume is the one feature tied to a specific flag: "Resume last conversation" is documented as passing --continue. Whether every listed backend accepts --continue is not stated in the material, and that is worth checking for whichever CLI you intend to use as your default.
The costs: Python as a runtime dependency, and a build step for contributors
Requiring Python 3 is the plugin's most consequential constraint. Obsidian itself does not need Python, so this plugin adds a runtime to your editor. On macOS and Linux that is usually a non-issue. On Windows it produces the interpreter-mismatch failure the README documents, and it produces it in a way that only surfaces after installation, when the sidebar prints the error. The plugin cannot fix this for you; it can only tell you which interpreter it picked.
The second cost is the base64 embedding. It buys compatibility with Obsidian's plugin directory layout, and it charges anyone who wants to patch the PTY layer: run ./build.sh or your change is invisible. The README also documents a development loop that assumes a scratch vault: symlink the repo into .obsidian/plugins/claude-sidebar, then toggle the plugin off and on in Settings after each edit. There is no hot reload described.
A third limitation is scope. The README's platform table marks macOS, Linux and Windows as supported and explicitly redirects mobile users to a different project, Claude Anywhere. If your workflow spans a phone and a desktop, this plugin covers only the desktop half. Nothing here is a defect; it is a boundary you should know before installing.
Terminal emulators and chat sidebars solve different halves of the problem
The closest comparison in kind is running the agent CLI in a normal terminal window next to Obsidian. That approach has no Python dependency, no pywinpty, no build step, and it survives any Obsidian update. What it lacks is the vault as a first-class target: no right-click folder launch, no send-selection-to-agent, no wikilink or drag-drop path handling, and no path translation when the CLI lives in WSL. Claude Sidebar is essentially those conveniences plus a pane. If you never need them, the plain terminal is strictly less machinery.
The other comparison is a chat-style assistant plugin that answers questions about your notes. That is a different product with a different contract: the model reads your vault and returns text you place yourself. Claude Sidebar hands the agent a shell in a directory. It can edit files, run commands, and act on the vault directly, which is why YOLO mode and folder targeting are framed as launch options rather than as a chat setting. Choose the sidebar when you want the agent to do work; choose a chat plugin when you want it to tell you something.
Maintenance, licensing, and what to check before you commit
The repository is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement, and it is worth noting that it does not carry any warranty. Nothing here is legal advice; if you redistribute the plugin or ship it inside a product, read the licence text in the repository rather than this summary.
Maintenance cost has two layers. The plugin layer updates through Obsidian's community plugin flow or the three curl commands above. The runtime layer is yours: Python 3, and pywinpty on Windows, kept installed in the interpreter the plugin actually selects. Release cadence visible in the material is frequent (1.9.5, 1.10.0 and 1.10.1 within roughly two weeks), which means manual installers should expect to re-run the update commands rather than treat installation as a one-time act. Contributors carry an additional cost: the PTY scripts are the part most likely to need platform fixes, and each change requires ./build.sh before it is testable in Obsidian. The README points contributors at CLAUDE.md for diagnosis, bug filing and pull requests, which is a reasonable first stop before reading main.js.
Editorial conclusion
Adopt Claude Sidebar if you already run an agent CLI in a terminal and want it anchored to a vault or an external project directory, and you are willing to keep Python 3 plus pywinpty current on Windows. Skip it if you need a mobile client (the README points to a separate project, Claude Anywhere) or if you would rather not run an agent with write access inside your notes. Before installing, confirm which Python interpreter the plugin selects on your machine, because the README warns that pywinpty installed into a different interpreter produces a "pywinpty not installed" error in the sidebar.
Community notes