Chatobby for Obsidian

A full agent workspace inside your vault.

Community: GitHub Discussions · Issue tracker · Documentation

Chatobby gives you a local-first agent workspace, built with first-class support for Obsidian and coding.

Chatobby can understand your notes, use tools, work across projects, recall memory and past sessions, and coordinate subagents when a task grows.

You can use a hosted model or connect a model server already running on your own computer. Each Vault or Project chat can also have a visible, user-editable chatobby.md system-prompt layer, so the way Chatobby works can fit the project without modifying the plugin or exposing private internals.

Your conversations, permissions, context, scheduled work, and delegated work all remain visible inside Obsidian.

Only model calls are sent to a provider of your choosing, with continuously updated support for OpenAI, Anthropic, DeepSeek, Google Gemini, Z.AI, Xiaomi, OpenRouter, Hugging Face, and many more. You can also connect a running local server that offers an OpenAI-compatible or Anthropic Messages-compatible API.

Models change more often than this README. See the maintained providers and models guide for provider variants, setup notes, and how to check the exact models available in your installed Chatobby version.

Though it can be, Chatobby is built not just to be another isolated chatbot sidebar. Chatobby is designed as a workspace in which an agent can help with real vault work, research, writing, planning, coding, Obsidian browser capabilities, and longer-running projects while you retain control over what it may do.

Public alpha: Chatobby is free while it is under active development. It is important to practice discipline with backing up important vaults and starting small to learn how to use Chatobby. Interfaces, behavior, and storage contracts may change between alpha releases.

Support Chatobby's development

If you like Chatobby and want to support its development and continuous updates, I would love to hear your feedback!

If you love Chatobby, and want to keep our devs (me) unemployed, I would greatly appreciate donations :") It's actually so exciting to see its capabilities now and I love doing this <3

Support is completely optional. It does not unlock features or change the free alpha experience.

Chatobby is available on Windows, macOS, and Linux. macOS and Linux support are experimental and have not yet been fully tested on physical hardware.

Contents

• Support Chatobby's development
• What makes Chatobby different
• The agentic experience
  • Run local models on your own hardware
  • Customize the system prompt for each workspace
  • Use terminal and Obsidian CLI capabilities
• Install
• A guided first fifteen minutes
• User guides
• Project guidance: chatobby.md, AGENTS.md, and CLAUDE.md
• Memory
• Context Queries
• Skills
• Tasks, roles, subagents, and channels
• Events
• Permission policies
• More things to ask Chatobby
• Platform and alpha status
• Privacy and data flow
• Source and licensing
• Help shape Chatobby

What makes Chatobby different

Most AI integrations stop at a chat box or QnA about your vault. Chatobby is built around the larger working experience required when an agent is allowed to do useful work, and track tasks for you.

The agentic experience

Work with your actual vault

Ask Chatobby about the note you are viewing, search for related material, compare ideas across folders, follow backlinks, open the right file, or request a precise edit. It can help preserve Obsidian-specific structure such as frontmatter, wikilinks, embeds, block references, tasks, tags, callouts, Canvas, and Bases rather than treating every note as generic text.

Examples:

• Summarize the active note and identify its unresolved questions.
• Find the notes that best support this claim and explain the connection.
• Turn these scattered research notes into a linked project index.
• Check this folder for unresolved links and propose a cleanup plan.
• Open the note where I last described the deployment problem.

See work happen, not just the final answer

Responses stream into the conversation while compact progress and tool activity remain inspectable. Permission requests appear where you are already working. Longer tasks can expose a small task list above the composer, and completed work collapses away instead of permanently occupying the interface.

You can stop a turn, inspect what the agent used, copy a full Markdown response, or select only the portion you need.

Type @ in the composer to attach a file or folder reference. Chatobby suggests the running Project's working folders first, including registered folders outside the vault, keeps matching while you type names that contain spaces, and closes the suggestion list only when you select an item or press Escape. Each selection becomes an openable chip. A reference tells the agent which item you mean; it does not bypass the active permission policy.

Work with images and documents

Paste an image into the composer or attach a supported document. Chatobby keeps the attachment visible with the message. Attached files can be opened through the operating system, while the document reader extracts bounded text from supported Office, OpenDocument, PDF, RTF, HTML, Markdown, CSV, and text files. Built-in OCR can recover text from image-only documents without requiring a multimodal model.

Understanding photographs, diagrams, page layout, and other visual meaning still depends on a multimodal model or a configured advanced OCR engine.

Continue real projects

Every chat belongs either to the Vault or to a Project. A Project keeps related conversations together and can include one primary folder plus other working folders, including folders outside the vault. Project creation can accumulate several folder selections at once and lets you choose which one is primary. Selected external folders are used in place; Chatobby does not create a same-named vault copy for them. Sessions retain their history, Project identity, and current working set so you can continue the real work later instead of starting from nothing.

Browsing the Projects page never silently changes the chat that is running. Open a stored chat to resume it, choose New chat in Project for a separate conversation, or move an existing chat between Vault and Projects from its context menu. Obsidian tabs remain the boundary between independent active conversations, while the agent rail switches between a main session and its subagents.

Project chat search can search either conversation names or message contents. Content results show the matching excerpts in bounded pages; selecting one resumes that chat and moves the feed to the exact highlighted message.

Right-click a folder, or a file inside it, to start Project work from that folder. The primary folder supplies the chat's working directory and relative path base; attached folders receive the same Project-root permission treatment. Adding either kind makes it available to the Project's chats without granting capabilities denied by the active permission policy. Paths outside the Project remain governed by the separate external-directory rule.

Customize the system prompt for each workspace

Chatobby automatically prepares a visible chatobby.md in the vault root for a Vault chat or in the primary Project root for a Project chat. Leave the properties alone and write ordinary Markdown below them to add durable naming, formatting, source, verification, or workflow preferences.

The body is a real lower-priority system-prompt section placed after Chatobby's protected built-in prompt—not a repeated user message. Body edits replace the old guidance on the next message you send. Advanced users can also switch optional built-in prompt modules on or off; those frontmatter changes take effect when a new chat or recreated/reconnected session runtime is prepared.

See Project guidance for the full property list and examples.

Use Chatobby for coding as well as notes

When the task is coding-oriented, Chatobby can treat the real repository, source files, project instructions, tests, logs, and built application as the primary working environment. It does not need to force ordinary coding work through vault search simply because the interface lives in Obsidian.

For Obsidian plugin development, the agent can combine repository work with read-only developer diagnostics for the live app, including console errors, DOM and CSS inspection, screenshots, and supported Obsidian CLI operations.

Examples:

• Diagnose this failing test, fix the cause, and run the focused verification.
• Review the current implementation against AGENTS.md and report concrete risks.
• Build the plugin and verify the affected workflow in the test vault.
• Inspect the live Obsidian console and determine why this view did not render.

Use terminal and Obsidian CLI capabilities

Chatobby treats ordinary files and bounded terminal scripts as the practical default for durable note, code, frontmatter, and bulk work. When a task actually benefits from Obsidian's running application, it can use the official Obsidian CLI for indexed search, history, link-aware changes, settings, plugin lifecycle, command-palette actions, and developer diagnostics.

At runtime startup Chatobby records a compact inventory of the commands available in the selected vault. If plugins change, the inventory refreshes. Exact default command grammar is maintained for the supported Obsidian CLI version; additional direct commands supplied by installed plugins are parsed from their live help. Known plugin integrations can add more precise guidance without making an absent command appear installed.

Detailed command schemas are disclosed only when Chatobby selects an exact capability, keeping ordinary chats compact. Every command still passes through the active permission policy and command-safety checks. See the Obsidian CLI and terminal guide.

Delegate without losing the thread

Create specialist subagents for bounded research, exploration, coding, review, or other focused work. The agent rail lets you move between the main agent and each active subagent. Every subagent has its own feed instead of being rendered as an undifferentiated block in the main conversation.

Reusable roles provide consistent instructions, model choices, limits, and permission policies. Launch direct bounded subagents for separable research, review, or implementation work; Chatobby keeps the main conversation as the supervisor and integration point.

Channels provide a durable, inspectable place for agent-to-agent communication. They are separate from user-facing session messages, so operational communication does not have to overwhelm the main conversation.

Keep useful continuity without hiding it

Chatobby uses several different continuity surfaces because they solve different problems:

• Session history preserves the chronological conversation and tool work.
• Memory stores user-approved durable facts, preferences, and decisions.
• Project guidance tells the agent how work in one project should be done.
• Context Queries compute small pieces of current project data.
• Skills describe reusable procedures.
• Tasks track the steps of the current session.
• Events trigger bounded future work.

These are not interchangeable. In particular, memory is not hidden policy, Context Query output is not a system instruction, and prompt text does not grant permission.

Automate deliberately

Events can represent one-off, scheduled, or repeating work. Each Event can be associated with a project, agent, permission policy, schedule, maximum runtime, and daily run limit. Run history remains visible so automated work can be inspected instead of disappearing into an unaccountable background process.

Examples:

• Every weekday at 6 PM, summarize today's project notes into the daily note.
• On the first day of each month, review unresolved tasks in this project.
• Tomorrow at 9 AM, launch the Research role with the review policy and summarize its result.

Choose what the agent may do

Permission policies control access to files, directories, commands, tools, settings, channels, and automated work. Choose a policy per session, switch it from the composer, respond to permission requests in the feed, and create more focused policies for particular roles or tasks.

Policies are separate from instructions. Telling the agent to edit a file does not silently bypass a policy that requires confirmation or denies the operation.

Bring the provider and model you want

Provider, model, and reasoning effort are session controls. Chatobby can use supported built-in providers and custom model metadata. The provider account, subscription, API key, and usage charges remain between you and that provider; Chatobby does not resell model tokens during the free alpha.

Run local models on your own hardware

Chatobby can connect to a server you already run through Ollama, LM Studio, vLLM, llama.cpp, or another OpenAI-compatible or Anthropic Messages-compatible endpoint. It can also start and supervise a local llama.cpp process on Windows, macOS, or Linux from Chatobby Settings -> Local model connections -> Managed llama.cpp. The ordinary connection form supports all listed server types; process startup is currently llama.cpp-specific. Managed profiles use validated settings, stay bound to 127.0.0.1, and never delete your executable or GGUF model.

The two sections represent different records and should normally remain paired:

For an existing Ollama, LM Studio, vLLM, llama.cpp, or compatible server, add only a connection. To let Chatobby launch llama.cpp, first save and test a loopback llama.cpp connection, then add the managed profile linked to it. The connection's provider ID and port must continue to match the managed profile.

The two Remove actions are intentionally different:

• Removing a connection removes its models from Chatobby and removes its stored credential. It does not stop the server or delete a linked managed profile. A remaining managed profile can still be started manually or at runtime startup, but chats cannot use it until a connection with the same provider ID is restored.
• Removing a managed profile stops a process owned by the current Chatobby runtime and forgets its launch settings. It does not remove the connection, executable, or GGUF file. The connection can still be used whenever another process serves the same endpoint.
• Stop is the right action when you only want to release RAM or VRAM while retaining both configurations.

You can also ask Chatobby to help choose a realistic local setup for your device. With permission, it can inspect relevant RAM, GPU, and VRAM facts, compare quantization and hybrid CPU/GPU offload, link current official setup guides, and explain what should be tested rather than treating hardware fit as certain. Chatobby never silently installs a server or model. You choose whether an existing server remains externally managed or Chatobby starts llama.cpp on demand, with the runtime, or manually.

See the providers and models guide for presets, API modes, field definitions, lifecycle choices, removal behavior, troubleshooting, and complete setup examples.

Research the current web

Chatobby includes account-free public-web search. In Chatobby Settings -> Web research, you can optionally connect your own Brave Search API key for stronger freshness, language, region, and date filtering. The key stays in Obsidian's secret storage. Search results identify whether basic search, enhanced search, or a genuine fallback was used, so an unconfigured provider is not reported as an outage.

Install

Recommended: install through Obsidian

1. Open Settings -> Community plugins -> Browse.
2. Search for Chatobby, then select Install and Enable.
3. Open Chatobby from the ribbon.
4. If the local runtime is missing, select Install runtime in the Chatobby view.
5. Review the requested installation and alpha notices, then confirm.
6. Open Chatobby, select the Settings gear in its top bar, then connect a provider or local model server. Credential values continue to use Chatobby's protected local credential store.
7. Return to Chatobby and send your first message.

The plugin downloads the runtime only after confirmation. It cryptographically verifies the release descriptor and included files, installs the runtime for the current operating-system account, and reconnects to it. When a compatible runtime update is available, Chatobby can present an update action inside the plugin.

Chatobby itself is free during the public alpha. The model provider you choose may require an account, API key, subscription, or usage payment.

For more detail, see the installation guide, alpha guide, and troubleshooting guide.

A guided first fifteen minutes

Start with the default permission policy and a copied test note.

1. Ask about what is open

Open a note and send:

Summarize the active note, list its open questions, and suggest one useful next step. Do not edit anything yet.

This demonstrates active-note context without immediately granting mutation authority.

2. Search across the project

Send:

Find the most relevant notes for this topic. Explain why each one matters and include wikilinks.

This tests discovery, evidence selection, and Obsidian-native output.

3. Approve one small edit

Send:

Add a short Next steps section to this copied note. Preserve its existing frontmatter and style, and show me any permission request that is required.

4. Attach something

Paste a screenshot or attach a small document, then ask Chatobby to summarize it or connect it to the current note.

5. Explore the workspace

Use the top ribbon to open Projects, Permissions, Memory, Events, Queries, Channels, Subagents, Plugins, and Settings. Projects replaces the former directory session picker with one searchable Vault/Project chat library. At the top of Settings, Add guide to vault can copy or update the linked Chatobby Guide. These pages are part of the same agent workspace; opening them does not change the Project or chat currently running.

User guides

These guides explain both the UI workflow and what to ask Chatobby when you want the agent to create or manage the feature for you:

You can build these features through their pages or describe the outcome to Chatobby and ask it to use the dedicated management tools. Chatobby never needs to inspect its own product source to use them.

Project guidance: chatobby.md, AGENTS.md, and CLAUDE.md

Chatobby supports both its own project-guidance file and the standard coding-agent instruction files. They overlap slightly, but they have different discovery rules and are most useful for different kinds of projects.

Neither file grants permission, and neither should contain secrets. Built-in safety, evidence, and permission behavior remains authoritative.

A simple chatobby.md

Start a new Vault or Project chat and Chatobby creates the file automatically. The generated file contains the current properties and an empty body. For the common case, leave the properties enabled and add plain Markdown below the closing --- line:

# Project guidance

- Preserve the existing note structure and writing style.
- Put new research notes in `Research/`.
- Link new notes to [[Project Index]].
- Ask before reorganizing folders or renaming existing notes.
- When writing a project report, distinguish confirmed facts from proposals.

The body becomes lower-priority project guidance for every chat in that workspace. It is sent as a system-prompt section after Chatobby's protected built-in sections, not as an ordinary user message.

Changing a Project's folder list does not silently change an existing chat's active root. If you need that chat to use another root's properties, move or reopen it against that root so its runtime is prepared with the correct cwd.

Use chatobby.md for durable conventions. Do not use it for:

• API keys or other secrets;
• a temporary one-turn request;
• large note collections that should be searched normally;
• permission grants;
• changing or bypassing built-in safety instructions;
• data that should be calculated afresh.

Advanced chatobby.md configuration

Most users should keep every built-in prompt section enabled. If you need a specialized project, frontmatter can independently control Chatobby prompt modules and workspace directories:

---
chatobby-prompt-schema: 1
chatobby-system-prompt: true
chatobby-task-guidance: true
chatobby-tool-guidance: true
chatobby-coding-workflow-guidance: true
chatobby-artifact-guidance: true
chatobby-memory-guidance: true
chatobby-personal-workflow-guidance: true
chatobby-subagent-guidance: true
chatobby-automation-guidance: true
chatobby-markdown-output-guidance: true
chatobby-artifacts-directory: .chatobby/workspace/artifacts
chatobby-sandbox-directory: .chatobby/workspace/sandbox
chatobby-tasklists-directory: .chatobby/workspace/tasklists
chatobby-reports-directory: .chatobby/workspace/reports
chatobby-inbox-directory: .chatobby/workspace/inbox
---

# Project guidance

Keep generated reports concise and link every report to [[Project Index]].

Current properties

Directory properties are conventions; changing one does not create that folder or grant access to it. Values must remain within the Vault or Project boundary. Disabling built-in sections can remove important behavioral guidance, so it is an advanced option rather than a recommended first customization. Runtime-owned product boundaries, immutable safety and confidentiality guidance, current environment facts, and the native skill catalogue remain enabled regardless of these switches.

A simple AGENTS.md

For a repository, put instructions such as these in AGENTS.md:

# Development rules

- Read the affected implementation before editing it.
- Preserve unrelated changes in the worktree.
- Run `npm run check` after code changes.
- Run focused tests for every modified test file.
- Do not build or publish a release unless explicitly requested.

Use additional AGENTS.md files in nested directories when a particular part of a repository needs more specific guidance. Existing CLAUDE.md files are supported as a compatibility alternative and use the same path-scoped loading. If both names exist in one directory, Chatobby uses a non-empty AGENTS.md for that directory. An empty AGENTS.md does not suppress compatible guidance in CLAUDE.md. Avoid duplicating contradictory rules across chatobby.md, AGENTS.md, and CLAUDE.md.

Long sessions and context compaction

Chatobby automatically compacts a long conversation before its working context becomes too crowded. If the threshold is reached during multi-step work, Chatobby waits for the current tool result, writes a continuity checkpoint, and then resumes the same request. It does not terminate or replay the operation that reached the boundary.

The checkpoint first aims to retain the most useful active skills, capabilities, and result handles. If that will not fit, it preserves the user's unresolved requests, active work, decisions, evidence, and next actions while dropping optional working context. If the model cannot produce a valid checkpoint after bounded corrections, the runtime constructs a conservative minimum from authoritative state rather than abandoning the session.

Memory

Memory is for durable knowledge that should remain useful across sessions: preferences, stable facts, project decisions, terminology, and established constraints.

Chatobby can surface a non-blocking memory suggestion in the feed. You can approve it, reject it, or ignore it. Pending suggestions remain available on the Memory page, where stored records can be reviewed, edited, archived, deleted, and inspected for history or technical details.

Good memory:

• The project uses Singapore time for all deadlines.
• The user prefers concise technical status reports.
• Deployment decision: use the staging vault before production.

Poor memory:

• a temporary task;
• a secret;
• a large transcript;
• an instruction intended to bypass permission;
• a value that changes every few minutes.

Follow-up obligations

An explicit commitment such as Remind me to email Sam after dinner can be stored as an active memory obligation. Unlike an ordinary recalled memory, the complete active set stays available across turns, compaction, and restart. Chatobby acts only when the stated conversation, work-event, or time evidence matches; ambiguous evidence leaves the obligation active instead of guessing.

The eventual action still uses the current permission policy. A time-based commitment that must fire without an active chat belongs to Events, while an obligation can preserve its user-facing identity and verified completion receipt.

Context Queries

Full instructions: Context Queries guide.

Context Queries are small project-owned scripts that produce typed data for an agent session. They are useful when current information should be computed from a local or external source instead of saved as memory or repeatedly searched by the agent.

A query runs at one of two times:

• Session start for information that should be established once when a session begins.
• Every turn only when a value can materially change between adjacent user messages.

Good examples include:

• current Git branch and changed-file count;
• current project milestone data;
• a small status summary from an approved local service;
• the current date or selected calendar state;
• bounded statistics derived from a project-owned dataset.

Avoid using a Context Query for:

• secrets;
• ordinary note retrieval;
• large datasets or documents;
• instructions or permission policy;
• data that does not need to be injected automatically;
• expensive work on every user message.

Use the Queries page to review names, descriptions, trigger timing, enabled state, and test results. Chatobby can also create, inspect, update, test, enable, disable, and delete queries through its dedicated tools. The Queries page keeps normal usage approachable rather than turning the interface into a code editor; the project retains the script files under .chatobby/queries/.

Example requests:

• Create a disabled session-start Context Query named Repository status. It should return the current branch and changed-file count. Test it, but do not enable it yet.
• List this project's Context Queries and explain which ones really need to run every turn.
• Test the project-status query and show me the typed result and any error.

Query code is trusted project code. Testing disabled code and enabling a query requires project trust and visible confirmation. Output is bounded and injected as untrusted contextual data, not as a system instruction.

Skills

Skills provide reusable procedures for recurring work. User and project skills can be selected when appropriate, while Chatobby also ships runtime-owned operating skills across Chatobby setup, coding and plugin development, agent coordination, source acquisition, Markdown vault work, structured data, visual communication, planning, automation, learning workflows, and Obsidian styling.

Runtime-owned skills are immutable and are not exposed as editable files or ordinary slash-command entries. A compact catalogue makes their names and purposes available at session start. The agent selects an entry semantically, then loads only the supporting references, scripts, fixtures, or verification checklists needed for the current step. This progressive disclosure avoids putting every specialist manual into every prompt.

Loading a native skill does not install an Obsidian plugin, grant a permission, or prove that a capability is available in the current vault. Chatobby still checks the installed environment and the active policy. For visual work, it also distinguishes structural evidence from rendered evidence: an audit can prove IDs, references, containment, and collision candidates without claiming that a diagram looks correct.

Use a project skill when the procedure belongs only to one project. Use a user skill when the procedure is genuinely reusable across projects. Do not put personal assumptions into a skill intended for other users.

Ask Chatobby to create managed skills as small documentation suites rather than one oversized prompt. A useful suite has one discoverable entry page, focused resources for deeper cases, primary references, failure and recovery guidance, and an executable or observable verification method. For example:

When Chatobby creates or updates a managed skill, the current view refreshes its skill slash commands and any open subagent role editor immediately. Invoking a skill shows a compact skill chip in your message; its expanded instructions remain agent context and are not presented as text you wrote.

• Load the relevant native guidance, then plan a large Canvas with a deterministic structural audit and a separate rendered review.
• Turn this QuickAdd workflow into a Project skill with exact API references, cancellation and rerun tests, and a live verification checklist.
• Create a user skill for this study-note method. Keep the entry concise and move notation rules and examples into focused resources.

The downloadable Chatobby Guide includes a complete beginner-facing page on native, user, and Project skills.

Obsidian views and Web Viewer pages

Chatobby treats Obsidian itself and a webpage opened in Web Viewer as two separate interactive surfaces. Obsidian panes, tabs, editors, plugin pages, Chatobby pages, focus, and workspace layout belong to the Obsidian host. The webpage inside a Web Viewer runs in its own page context with different content, controls, console messages, and element references.

This distinction lets Chatobby inspect or operate the intended surface without mistaking an Obsidian control for a webpage control. A Web Viewer tab can still be selected or closed as an Obsidian pane, but reading, clicking, typing, and page diagnostics happen inside its webpage. Host-interface and webpage references are not interchangeable.

Tasks, roles, subagents, and channels

Full instructions: Subagents guide.

These surfaces cover different levels of coordination:

Start with one subagent when a task has a clearly separable research, review, or implementation component. Add another only when the work is genuinely independent enough to benefit from parallel execution.

Example requests:

• Delegate a bounded review of these sources to one research subagent. Limit it to five sources and reconcile the findings here.
• Create a reusable role for web-only fact checking with a focused permission policy.
• Launch a review subagent for this migration and ask it to report only material risks.
• Show me every active subagent and any permission request that needs my decision.

The main agent remains the supervisor. Delegation must not be used to bypass permissions or conceal work from the user.

Events

Full instructions: Events guide.

Events are durable triggers for future agent work. Use them when the timing is part of the requirement rather than merely another step in the current conversation.

When creating an Event, review:

• project directory;
• assigned agent;
• permission policy;
• date and time;
• repetition and end condition;
• maximum runtime;
• daily run limit;
• expected output and failure behavior.

Do not use an Event as an invisible permission escalation. Scheduled work uses its assigned policy and remains visible in run history.

Permission policies

New sessions begin with Obsidian, the vault-focused default. Approve safe asks before potentially unsafe work, Full access permits the broadest surface, Read only blocks changes, and Auto privately classifies the checks that Approve safe would otherwise ask you to decide. Auto may add a small model request before a tool runs and fails closed if classification cannot complete. Create narrower custom policies for specialized roles, web-only research, automation, or sensitive projects.

The Permissions page shows Current chat separately from Default for new chats. A chat explicitly bound to Full access continues to use Full access even when Obsidian is the installation default. The default is not evidence of the open chat's effective policy, and each tool operation is still checked against the effective binding when it runs.

Reloading or restarting the Obsidian application always asks for a fresh user decision. Full access, Auto classification, and an earlier approval for another Obsidian CLI command do not authorize those application-lifecycle actions.

When customizing a policy:

1. Inspect the current policy rather than overwriting it blindly.
2. Decide whether each capability should allow, ask, or deny.
3. Keep file, external-directory, command, settings, tool, and channel access conceptually separate.
4. Save the customized policy without assuming that customization should also assign it to the current session.
5. Select the policy explicitly for the session or role that should use it.
6. Verify the saved rules after changing them.

Permission instructions do not belong in chatobby.md, memory, Context Query output, or an agent message. The Permissions page and permission tools are the authority-bearing surfaces.

Connected MCP plugins appear as separate capability groups after discovery. Their tools start denied in every policy until you explicitly choose Allow or Ask; connecting a service does not grant an agent permission to use it.

More things to ask Chatobby

Vault and knowledge work

• Compare my notes on these two approaches and create a decision table.
• Find claims in this draft that need sources and locate supporting notes.
• Turn this lecture transcript into revision-ready Obsidian notes.
• Trace the backlinks around this concept and identify missing connections.

Planning and administration

• Review this project's recent sessions and give me a compact continuation brief.
• Find incomplete tasks related to the move and group them by urgency.
• Create a one-off Event for this deadline with a conservative permission policy.

Research

• Research this question on the web, preserve source links, and compare the findings with my vault.
• Open this page in Web Viewer, inspect its actual content, and extract the relevant evidence.
• Use two bounded subagents to research opposing views, then reconcile disagreements.

Coding and plugin work

• Inspect the repository instructions and determine the correct test command before editing.
• Fix this regression, add a focused test, and verify the built Obsidian workflow.
• Check the live plugin console and DOM state rather than guessing from the source alone.

Platform and alpha status

The current alpha supports desktop Obsidian on Windows 10 or 11 x64, macOS 11 or later on Apple Silicon and Intel, and glibc-based Linux on x64 and arm64. macOS and Linux packages are built and exercised on native GitHub runners, but neither platform has completed representative physical-device acceptance. Flatpak, Snap, musl, and other confined Linux environments remain unverified.

Important limitations:

• Chatobby uses a separate local runtime in addition to the Community plugin.
• The runtime executable is cryptographically verified by Chatobby but is not currently Authenticode-signed, so Windows may show a publisher warning.
• macOS uses an ad-hoc code signature rather than Apple notarization and may require one explicit Open Anyway approval. Chatobby never changes Gatekeeper or quarantine settings.
• Linux support currently targets ordinary glibc desktop installations. A libc or confinement mismatch fails before execution and keeps the previous runtime available.
• Provider availability, multimodal support, and tool calling depend on the selected model and provider.
• Agent actions can modify files or run commands when permitted. Begin with a copied note or test vault and review permission prompts.
• Alpha storage and configuration formats may require migration between releases.
• There is no Chatobby account or Chatobby subscription during the free alpha. Provider costs are separate.

Privacy and data flow

• Local connection: The plugin communicates with the runtime over an authenticated local connection.
• Model requests: The runtime sends the request and relevant context to the model provider you select.
• Tools and integrations: Websites or external services are contacted only when requested or authorized through the relevant capability.
• Files outside the vault: External files are read only when attached or when the active permission policy authorizes the runtime operation.
• Update check: The plugin checks a signed GitHub update descriptor. Vault and conversation content is not included in that check.
• Telemetry: The plugin contains no client-side product telemetry. Chatobby does not currently collect product analytics or server-side telemetry.
• Secrets: Do not put credentials in notes, chatobby.md, AGENTS.md, memory, Context Query output, or chat messages. Use supported credential storage and settings.

Source and licensing

The reviewable Obsidian connector is source-available under proprietary terms and is not open source. The separate runtime is closed source and has its own distribution terms. See LICENSE, PRIVACY.md, and the responsibility boundaries.

Help shape Chatobby

This is an alpha because feedback still has real influence over the product.

• Report reproducible defects through the issue tracker.
• Use GitHub Discussions for questions, ideas, workflows, polls, and general feedback.
• For security concerns, follow SECURITY.md.
• If Chatobby has been useful and you want to support continued development, join the Patreon.

Useful feedback includes:

• what you tried to accomplish;
• what you expected to happen;
• what actually happened;
• the Chatobby and runtime versions;
• whether the problem survived an Obsidian restart;
• screenshots or logs with private data removed.

Contact: [email protected]

The Community plugin is the reviewable Obsidian interface. The separately distributed runtime owns private model orchestration and agent services. The two processes communicate over authenticated local loopback connections.

npm install --ignore-scripts
npm run check
npm run build

npm run build:release requires CHATOBBY_RUNTIME_PUBLIC_KEY, disables source maps, and stages exactly main.js, manifest.json, and styles.css under release/.

Reviewers can also consult the responsibility boundaries, managed runtime lifecycle, and release boundary.