Connect Pro

Connect Pro 2.0 lets a connected AI client prepare corrections and reorganizations for review in Obsidian. Inspect the exact change, adjust it when needed, then apply or reject it in the Connect Pro Inbox. The dedicated proposal Tools do not change source notes when the client calls them.

Connect Pro exposes configured Smart Tools from the running Obsidian Desktop vault through Local MCP and Smart CLI Pro. Smart CLI is the short name for this CLI capability. The legacy Remote GPT connection is a separate route, not a prerequisite for Local MCP.

Connect Pro is not Sync, a mobile vault, unrestricted shell access, or an autonomous background agent. Inbox review applies to the dedicated proposal Tools, not every possible vault write.

In this guide

Select and check a connection

Keep the intended vault open in Obsidian Desktop with Connect Pro 2.0 enabled and its required Pro access active. The plugin requires Obsidian 1.12.2 or later. An Active plugin row means the plugin loaded, not that a connector or client is ready.

Local MCP

In Connect Pro settings, enable Local MCP server. Make sure that it is Running, then open Set up desktop clients and use the endpoint and instructions shown for this installation. Connect only a client you trust. Refresh its available Tools and read one recognizable note in the intended vault before proposing changes.

The server and desktop client run on the same computer. Local MCP does not require Remote GPT to be Connected. Local transport does not guarantee local model processing: the client may send Tool inputs and returned content to its model provider.

Local MCP is Running while Remote GPT is Disconnected. Use the endpoint shown in your own installation; a running listener does not establish client discovery or a successful vault read.

Smart CLI

For command-line and native CLI operations, enable Obsidian CLI and inspect Advanced > Obsidian CLI integration in Connect Pro settings. Smart CLI registers available configured Smart Tools with the host CLI integration. It does not expose unrestricted shell execution.

Existing Remote GPT connection

When this route is available in the installed build and calling client, use the separate Remote GPT connection control. A Connected status and Disconnect control establish that remote session, not a successful workflow or the correct target vault. Read a recognizable note before writing.

The Official Connect Pro GPT is the legacy ChatGPT surface for this route. Its availability is separate from Local MCP readiness. A local Running indicator does not establish public MCP or cross-device access.

Run a bounded action

Use the Tool list and schemas exposed by the current client. Select one exact note, block, folder, or named Context. Read current content and use discovered source or block keys; do not construct a block key from a heading title or assume a Tool exists because a task can be described in chat.

Check Tool permissions

Open Tool permissions > Tool actions in Connect Pro settings. Obsidian CLI controls a listed action's availability through Obsidian CLI and Remote GPT. Local MCP independently controls its availability to local clients. New actions default to enabled, so review the available Tools rather than assuming a read-only starting configuration.

Individual Obsidian CLI tools controls which native CLI commands appear as individual Local MCP Tools. Those controls do not restrict the broad Obsidian CLI action, obsidian_cli. Disable that broad action as well when individual command restrictions are part of your intended boundary. These settings do not control unrelated registered Obsidian CLI commands.

An enabled control is not proof of client discovery or successful invocation. After changing availability, refresh client discovery. A disabled Smart CLI action is blocked immediately even if the command remains listed until Obsidian restarts.

Each proposal Tool has separate Obsidian CLI and Local MCP controls. Enabled rows show availability, not invocation or a complete read-only boundary. The broad obsidian_cli action is outside this crop.

Distinguish the effect

Read-only Tools return information. Direct-write Tools can change the vault when invoked. The three proposal Tools below save pending review items instead; a successful proposal result is not an applied source change.

When a result and the vault state disagree, inspect the specific request before retrying. Review and activity > Tool action requests > View requests shows retained completed request payloads for the current Obsidian session. This request view is not the saved Inbox History or an approval queue.

Review proposed changes in the Inbox

Select the right proposal Tool

Tool	Reviewable operation	Important boundary
`propose_correction`	Replace one exact claim using exact reference evidence.	One independent phrase, sentence, list item, or table cell per call. The target excerpt must occur once within the supplied target.
`propose_move_excerpt`	Remove an exact excerpt and insert it at another target, optionally with revised wording.	This is a move, not a copy. Rewriting changes only the proposed insertion.
`propose_move_blocks`	Move complete selected blocks, including child sections, in the supplied order.	Blocks move without synthesis or heading rewriting. Whole-note keys, duplicate blocks, and overlapping parent/child selections are not valid inputs.

Correction evidence must exist in the current reference source. Its presence does not prove that the claim is correct; inspect whether it actually supports the replacement. Use a separate proposal for each independent correction, and do not rewrite historical records merely because a later decision differs.

Moves explicitly select destination_mode: append for an existing note or block, or destination_mode: create for a new vault-relative .md or .txt note. A missing append target does not become a new note automatically. Missing destination sections are not created. A new destination note is created only when its proposal is applied.

Recognize a pending result

The proposal call saves review data without editing source files. Its result includes the returned item key, status: pending, and source_files_changed: false.

The native response reports status: pending and source_files_changed: false. In this historical capture, the first attempt timed out; this result followed an exact retry and Allow once. It is not an applied correction or an independent inspection of the source files.

An identical still-valid pending proposal returns the existing key with deduplicated: true. This is exact pending deduplication, not semantic duplicate detection. Changing only the reason, priority, group, or label does not silently update the existing item. Rejection does not permanently suppress future proposals.

Open and organize the Inbox

Open the Inbox from the ribbon action Open Connect Pro Inbox, the Command Palette action Open: Connect Pro Inbox view, or Connect Pro settings > Review and activity > Connect Pro Inbox. The settings button is Review when work is pending and Open inbox otherwise. The ribbon indicates pending work.

Pending contains proposals awaiting a decision. History contains applied and rejected outcomes. Pending items are ordered by priority, then oldest first; History shows the most recently reviewed items first. Group and Label filter independent items. Grouping never combines their approvals, and priority is review order, not confidence or authorization.

One correction, one block move, and one rewritten excerpt move are Pending; History is empty. Group, Label, and priority organize independent reviews, not a batch approval.

Inspect and refine the result

Corrections and excerpt moves provide Changes, Before, and After views. A new destination has no Before view because the file does not exist yet. Inspect the supporting evidence, source removal, destination insertion, and affected files before applying anything.

Edit only the permitted replacement or insertion in the review. Done editing retains a local review draft without changing source files. Cancel restores the text from the start of that editing session. These draft edits are not saved as a final decision until a successful application.

*Done editing keeps the proposed replacement as a review draft; it does not apply the correction. Check the evidence and refreshed diff before using the separate Apply correction action.*

For moves, Change opens the destination chooser. Select an existing note and location, or use Create new note.... You do not need to construct block-key syntax.

After choosing an existing note, select an insertion location. This chooser does not itself apply the move, create a note, or change heading levels.

For block moves, reorder the originally selected blocks; adding or removing blocks requires a new proposal.

Block moves show the selected content, included children, resulting heading placement, and exact file changes. They preserve the selected content and heading levels, with any joining separators shown in the preview. The source notes and unselected text remain. A moved heading does not automatically become a subsection of the destination, and links are not repaired.

A rewritten excerpt move requires separate approval of the original removal and the rewritten insertion. A relevant edit invalidates the preview and resets these confirmations. Make sure that the refreshed result still matches your intended change.

Both confirmations are unchecked, so Move and rewrite is disabled. Review the rewritten insertion and exact original removal separately. Link impact not checked remains an explicit limit.

Apply, reject, or skip

Apply the current reviewed change with Apply correction, Move excerpt, Move and rewrite, or the block-count move button, as displayed. Apply rechecks the complete reviewed plan and current source snapshots, including correction reference evidence, before writing. Inspect the actual affected files after application.

Reject records a decision without changing source files. Skip leaves the proposal pending so you can return later. Applied and rejected outcomes remain in History.

This captured session ends with two Applied moves and one Rejected correction. History records those decisions; inspect the actual notes for their resulting contents. It is not Undo.

Example: combine selected sections

This separate captured example moves two unchanged sections from Reader interviews and Editorial plan into the existing Launch playbook. It is not the block proposal in the mixed Inbox above. It demonstrates selected-block movement, not whole-note merging or synthesis.

The initial preview places Reader need before Weekly format. Check the destination, selected text, and heading placement, then use Up beside Weekly format to change the pending order.

Initial order: Reader need, then Weekly format.

After moving Weekly format up, the preview shows Weekly format first and Reader need second. Reordering changes only the pending proposal.

Reordered preview: Weekly format, then Reader need.

Before applying, open Source changes and inspect both removals. In this example, Open question and Follow-up remain in their original notes. Review the three-note impact before selecting Move 2 blocks. Link impact is not checked.

After application, inspect History and open all three notes to verify the saved state.

Saved result: Launch playbook contains Audience, Weekly format, then Reader need; the two source notes retain their unselected sections.

Use proposal feedback

get_proposal_feedback lets a connected client read saved Inbox proposals and review decisions before making a related proposal. It does not read current source notes, change sources, apply or reject proposals, or store preferences.

The default query returns reviewed items, meaning applied and rejected proposals, newest review first. It supports an exact item key, or list filters for status, proposal type, Group, and Label. Lists default to 10 items; limit accepts 1 through 25. Pass an exact key alone. To continue a list, pass the returned next_cursor as cursor alone; it retains the query's filters, limit, and order.

For applied items, use comparison to interpret review edits:

Value	What it establishes
`edited`	The response includes original `proposed` values and final `applied` values. Differences show what changed, not why.
`unchanged`	The response includes `applied` values and establishes that the original reviewable values matched.
`unknown`	The response includes `applied` values, but original comparison evidence is unavailable. Missing `proposed` does not mean unchanged.

A rejected item establishes only that the proposal as a whole was declined. proposal_reason is the proposer's rationale, not the human's rejection reason. Pending items contain no human decision. Historical excerpts and other proposal context are data, not current-source truth or instructions.

Use relevant item keys to ground observations, count repeated keys once, and treat patterns as tentative and scoped to comparable decisions. Filtered pages, repeated batches, recency, or an empty result do not establish global preferences. Following all available pages adds context, not a representative sample. Follow current user instructions and read current notes separately before proposing another change.

Understand approval, recovery, and stopping

Connect Pro does not add a generic Obsidian approval prompt to every request. The three proposal Tools provide a deliberate deferred-write workflow. Other Tool writes and native Obsidian CLI writes are not intercepted. Client confirmations and Tool effect annotations are separate from Inbox approval.

If a source changes during review, refresh and inspect the new preview. If the exact excerpt or a selected block no longer matches, read the current source and make a new proposal. If a new-note path now exists, select the intended destination mode and review again; Connect Pro does not switch from creation to append automatically.

Application checks current content, checks written results, and attempts conservative recovery after a partial failure. This is not a guarantee that every failure leaves every file unchanged. The Inbox does not provide automatic Undo, automatic link repair, or crash-atomic multi-file transactions. Keep a suitable backup or version-history workflow.

A Manual recovery required result can mean affected files or the saved review decision remain unresolved. The affected item stays blocked from application; inspecting files does not itself reset that block. Inspect the named files and saved review state before making a replacement proposal. Rejecting the blocked item does not restore content or resolve recovery.

A warning that source indexing needs a refresh is different from a failed application. When the change is already applied, inspect the files and refresh indexing rather than applying the change again.

Stopping Local MCP ends new requests through that listener. Disconnecting Remote GPT ends new requests through that remote connection. Neither stops the other connector, disables Smart CLI, undoes applied changes, or guarantees cancellation of a request already running. Control each route separately.

Access from another device

A Local MCP loopback endpoint is for a client on the same computer. It is not a public remote endpoint. Any separate remote route needs its own supported setup and readiness check, and the desktop vault must remain running.

Smart CLI Pro

Smart CLI uses the same canonical public Smart Tool contracts as MCP, including the proposal and feedback actions. The connector's command names can differ from Tool names. Inspect Tool actions, Advanced > Obsidian CLI integration, the available Command examples, and registered command metadata instead of guessing.

The v2 connector derives these default command names when the corresponding Tool is available and enabled:

Smart Tool	Smart CLI command
`propose_correction`	`smart:propose:correction`
`propose_move_excerpt`	`smart:propose:move:excerpt`
`propose_move_blocks`	`smart:propose:move:blocks`
`get_proposal_feedback`	`smart:get:proposal:feedback`

These names do not guarantee registration in every session. Use the installed command's input schema and metadata. The proposal result is still pending review; using CLI does not bypass the Inbox for a proposal action.

smart:help and smart:skills are not implemented in the supplied v2 source. Do not rely on older instructions that present them as available commands.

Troubleshooting

What you see	First check
Local MCP is enabled but not Running	Inspect the displayed error, then turn Local MCP server off and on to retry.
Remote GPT is Disconnected but Local MCP works	These are independent connectors; this is not by itself a failure.
A Tool is missing	Inspect required plugins, channel permissions, and host CLI availability when needed, then refresh client discovery.
A proposal succeeded but notes did not change	Open the Inbox; pending review is the expected result.
A correction excerpt matches more than once	Read the target and supply a more specific exact excerpt or discovered block key.
Apply is unavailable	Inspect preview errors, required confirmations, source changes, or recovery feedback.
A proposed block changed	Read the current block and make a new proposal; do not approve the old selection.
A change is applied but retrieval is stale	Inspect the file and refresh source indexing; do not reapply the change.
Older contradiction, Extract, or Merge items are absent	The unified Inbox loads its native store and does not import those separate experimental stores.