Getting started with Connect Pro

Start with one read that matches the intended vault. Then use a disposable target to complete the Connect Pro 2.0 propose-review-apply workflow. A pending proposal is the first result, not a completed source change.

1. Open the intended desktop vault

Use Obsidian Desktop 1.12.2 or later with Connect Pro 2.0 enabled and its required Pro access active. Keep the intended vault open. An Active plugin row confirms loading, not client connectivity.

2. Select one calling route

For Local MCP, open Connect Pro settings and enable Local MCP server. Make sure that it is Running, then use Set up desktop clients with the endpoint shown for this installation. Follow the installed instructions for your supported client on the same computer. Remote GPT does not need to be connected.

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.

For Smart CLI Pro or native CLI operations, enable Obsidian CLI and inspect Advanced > Obsidian CLI integration. Smart CLI uses the same underlying Smart Tool contracts. An existing Remote GPT integration uses its own connection and support requirements; do not mix its readiness checks with Local MCP.

Open Tool permissions > Tool actions and review availability for your selected channel. New actions default to enabled. For a proposal-only write workflow, retain the reads you need and the selected proposal action, and disable unrelated direct-write actions exposed through that channel. In Local MCP, also disable the broad obsidian_cli Tool when you need individual CLI restrictions; its access is not restricted by the individual command toggles.

Only connect a client you trust. Local MCP describes local transport, not a guarantee that the client's model provider receives no vault content.

3. Check one read-only result

Refresh the client's available Tools. Read one recognizable note by its exact discovered key and compare the returned text with that note in Obsidian. Do not expand scope or write when the route or target is uncertain.

4. Propose one correction

Select a disposable target note and a reference note that contains a clearly different, accurate claim. Make sure that the target and reference excerpts are current and exact. Use one small phrase or sentence, not a whole-page rewrite.

For example, manually prepare two disposable notes: a reference stating The review happens on Friday. and a target stating The review happens on Monday. Then use this request, replacing the bracketed names with those notes:

Read [reference note] and [target note]. Use propose_correction to propose replacing the target's Monday claim with the exact Friday claim supported by the reference. Use one correction, Group "Connect Pro first review", and Label "Setup test". Do not use a direct-write Tool or native CLI write. Leave the change pending for me to review in Obsidian and report the returned item key.

The Tool result should include status: pending and source_files_changed: false. Open the target note and make sure that its text is still unchanged. Do not repeat the request merely because the note has not changed yet.

For a first move instead, use propose_move_excerpt for one exact passage or propose_move_blocks for complete discovered blocks. Select append or create explicitly. A new destination note should not exist until application.

5. Review in Obsidian

Open 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 > Review.

Inspect the target, rationale, reference evidence, and Changes, Before, and After views. A reference excerpt is supporting evidence to evaluate, not a guarantee that the proposed claim is correct.

Edit the proposed replacement in place when needed. Done editing retains the local draft without applying it; Cancel restores the text from the start of that editing session. Wait for a current preview before deciding.

For moves, Change selects an existing note and location or Create new note.... A new destination has no Before view because the file does not exist yet. Rewritten excerpt moves need separate removal and rewritten-insertion confirmations. For block moves, inspect included children, final order, heading placement, and exact file changes. A moved heading is not automatically nested or rewritten.

6. Apply or reject and inspect the outcome

For the correction, select Apply correction only when the current preview is ready. Compare the actual target note with the reviewed result and make sure that the reference note is unchanged. The item should appear as Applied in History.

Reject records a decision without editing source files. Skip leaves the proposal pending. For this first test, an applied change that matches the preview or an intentionally rejected proposal with unchanged sources is a complete reviewed result.

When a preview is stale, inspect a fresh preview. When an exact excerpt or selected block no longer matches, read current content and make a new proposal. A manual-recovery warning requires inspection of the named files and saved review state; it is not permission for a blind retry. The blocked item does not become applicable merely because you inspected it.

The Inbox has no automatic Undo or automatic link repair. Recovery protection is not a crash-atomic multi-file transaction. These limits apply even to a small test.

7. Read the decision and stop the route you used

When get_proposal_feedback is available and enabled, ask the client to read the returned item key. It should describe the recorded decision. For an applied item, inspect comparison and the final applied values. A rejected item does not contain a human rejection reason merely because it contains proposal_reason.

Stop Local MCP when finished with the local client, or disconnect Remote GPT when finished with that route. They are independent controls, not a global cancellation or Undo mechanism. They do not disable Smart CLI. Applied changes remain, and an already-running request is not guaranteed to be canceled.

Example: review a rewritten excerpt move

The Monday/Friday correction above is a disposable exercise, not a recorded run. This separate historical example follows one proposed move from Launch working notes into a new Reader voice note. It illustrates the review checkpoints, not completion of the exercise or a new v2 acceptance run.

Choose the suggestion

In Pending, select Review beside Move excerpt to Reader voice. Other pending proposals have their own decisions.

Follow the Reader voice proposal. The correction and block move have their own independent decisions.

Adjust the insertion

Check the destination. Use Edit insertion to adjust the proposed text, then Done editing. Editing this draft does not create Reader voice or remove the source excerpt.

*Done editing keeps a local draft. It does not create Reader voice or remove the original excerpt; a new destination has Changes and After, but no Before view.*

Review both changes

Read the final insertion and the exact original excerpt marked for removal. This is a move, not a copy. Reject the suggestion when the proposed changes are not useful.

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.

Confirm and apply

For this rewritten move, check Approve inserting the rewritten text and Approve removing the original excerpt. Select Move and rewrite only after both changes match your intent and the preview is ready.

Both confirmations are checked and the action is ready. This is still a pending proposal, not an applied move or an already-created destination.

Verify the outcome

In History, open Details for the Applied Reader voice move. Compare Original excerpt with Insertion, then open the source and destination notes to verify removal and insertion. The stored original excerpt is historical text, not proof that it remains in the source.

*Applied records the decision and final insertion. Original excerpt is retained historical text; inspect both notes to verify the current removal and insertion.*

These screenshots are checkpoints from one review session, not a continuous recording, so Pending and History counts change between steps. Follow the Reader voice proposal and note names rather than the counts.

Continue after the first result

Use a named project or small review batch. Group and Label help locate independent decisions; priority affects their order, not confidence or shared approval. Expand only after the read, pending proposal, human decision, and resulting file state consistently match.

Use prior feedback as scoped historical evidence. Read current notes and follow current instructions for each new proposal. The history is not automatic preference learning or authorization to apply changes.

See the documentation for Tool contracts and boundaries and the FAQ for pending results, duplicates, recovery, and connection distinctions.