Oh My Claudian

Oh My Claudian is an Obsidian plugin that embeds coding agents in your vault. Agents can read, write, search, run commands, and carry out multi-step workflows in the vault working directory.

Install from Obsidian Community Plugins · View on GitHub

This repository is based on YishenTu/claudian and adds Oh My Pi (OMP) support through ACP.

Added in This Repository

• Oh My Pi (OMP) — An ACP-backed OMP provider with model discovery and selection in the chat sidebar.

Features

• Sidebar chat, multiple tabs, conversation history, fork, resume, and compact.
• Inline edits with word-level diff preview.
• Slash commands, skills, @ mentions, and instruction mode.
• Provider-specific planning, permissions, reasoning controls, and model selection.
• MCP support where available from the selected provider.
• Internationalized interface with 10 locales, including Simplified and Traditional Chinese.

Requirements

• At least one supported harness:
  • Claude Code CLI
  • Codex CLI
  • Grok Build
  • OpenCode
  • Oh My Pi (OMP)
  • Pi
• A compatible subscription or API provider.
• Obsidian v1.7.2+ on macOS, Linux, or Windows.

Installation

From Obsidian Community Plugins (recommended)

1. Open Obsidian → Settings → Community plugins → Browse.
2. Search for Oh My Claudian, install it, and enable the plugin.

You can also open the Oh My Claudian community plugin page directly.

From source (development)

cd /path/to/vault/.obsidian/plugins
git clone https://github.com/lee259/oh-my-claudian.git
cd oh-my-claudian
npm install
npm run build

Then enable the plugin in Obsidian under Settings → Community plugins.

Usage

Open the chat sidebar from the ribbon icon or command palette. Select text and use the inline-edit hotkey to edit notes with a diff preview. Use / for commands and skills, @ to reference vault files or provider resources, and the provider selector to choose Claude, Codex, Grok, OMP, OpenCode, or Pi.

OMP requires its CLI to be installed and logged in separately. In Settings → Oh My Claudian → OMP, enable the provider, set the CLI path if it is not detected automatically, and use Discover to load available models.

Development

npm run dev
npm run build
npm run typecheck
npm run lint
npm run test

Release

Releases are created automatically by .github/workflows/release.yml when a version tag is pushed.

1. Update the version in manifest.json and commit the change.

2. Run the local validation checks:

   npm run typecheck
   npm run lint
   npm run test
   npm run build
   

3. Create a tag that exactly matches the manifest.json version, for example:

   git tag 2.1.2
   git push origin 2.1.2
   

   If your writable remote is named fork, use git push fork 2.1.2 instead.

The workflow validates the version, builds the plugin, runs the performance check, generates release notes, and publishes main.js, manifest.json, and styles.css to the GitHub Release. These are the files used for the Obsidian Community Plugins release.

Privacy

Your input, attachments, and tool results are sent only to the provider you select: Claude, Codex, Grok, OMP, OpenCode, Pi, or their configured model providers. Oh My Claudian does not send telemetry. Network activity is limited to explicit provider work and configured MCP endpoints.

Troubleshooting

If a provider CLI is not found, first leave its configured path blank so Oh My Claudian can auto-detect it. If detection fails, set the executable path in the provider settings and ensure its runtime is available to Obsidian's PATH.

For OMP specifically, verify that the CLI is installed, logged in, and executable by the Obsidian desktop process. If model discovery fails, set the absolute OMP path in the OMP settings tab and try Discover again.

Architecture

src/
├── app/          # Application services and persistence
├── core/         # Provider-neutral contracts and runtime
├── providers/    # Provider adaptors, including ACP and OMP
├── features/     # Chat, inline edit, and settings UI
├── shared/       # Reusable UI components
└── style/        # Modular CSS

Contributing

Issues and focused pull requests are welcome. Before opening one, please search existing issues and pull requests to avoid duplicates. For substantial changes, open an issue first so the problem and scope can be discussed.

Pull requests should focus on one problem and explain:

• Why the change is needed and who it affects.
• What behavior or code changed, and why this approach was chosen.
• How it was validated, including tests and manual checks.
• Known limitations, compatibility risks, and follow-up work.

Add or update tests for behavior changes, preserve provider ownership boundaries, avoid unnecessary production dependencies, and update documentation for user-facing changes. New provider additions are not accepted; improvements to existing providers should document provider-specific capabilities and limitations.

See CONTRIBUTING.md for the full development and pull request guide.

License

Licensed under the MIT License.