[FEATURE] Extend VS Code rendered markdown commenting to any file edit, not just plan mode

Resolved 💬 3 comments Opened Apr 1, 2026 by yosibe Closed Apr 1, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

VS Code has a powerful but little-known feature: when viewing rendered markdown in the editor, users can select text on the rendered view and attach inline comments directly to specific sections. The Claude Code VS Code extension already leverages this in plan mode — when the agent writes a plan (markdown file), the user reviews the rendered output and leaves inline comments that are fed back to the agent. The agent receives both the selected text and the comment content.

However, this rendered-markdown commenting is currently limited to plan files only. Plan mode is read-only (the agent cannot run scripts or edit other files), so it cannot be used for workflows that require active editing alongside review. Users who need iterative, comment-driven review on real files (e.g., architecture specs with embedded images) are forced to fall back to chat-based feedback, losing the ability to visually point at specific sections in the rendered document.

Proposed Solution

Provide a general-purpose mechanism for the user to attach inline comments to any rendered markdown file and have the agent receive them. This is not an accept/reject flow — it's a user-initiated review action:

  1. The user tells the agent they want to place comments on a specific markdown file
  2. The agent opens the file in the VS Code rendered markdown view and waits for comments
  3. The user reads the rendered document (with images, diagrams, tables), selects passages, and attaches inline comments
  4. When ready, the user signals the agent to proceed — the agent receives all comments and acts on them

This is a building block, not a complete workflow. Custom skills and hooks can be built on top of this mechanism to create domain-specific review workflows (e.g., iterative spec writing, document review, technical editing).

Alternative Solutions

  • Plan mode with symlinks: Use a symlink from the plan file to the real spec file, so relative image paths resolve. Fails because plan mode is read-only and cannot run scripts needed for editing.
  • HTML comments in markdown: Insert <!-- REVIEW: ... --> comments in the source. Fails because HTML comments are invisible in the rendered view — the user would have to switch to source view, defeating the purpose.
  • Chat-based feedback: The user describes what to change by referencing sections in the chat. Works, but is significantly less efficient than inline comments — the user must quote text and describe locations rather than simply pointing at content.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Iterative architecture specification writing. An agent edits a spec (markdown with embedded images and diagrams), and the user reviews the rendered output and provides inline feedback by commenting directly on the formatted document. This is typically a long, multi-round iterative process — the user provides targeted feedback on specific sections, the agent updates, and the cycle repeats many times. This requires:

  • Editing the real file (not a plan file) so relative image paths and embedded images resolve correctly
  • Running bash/python scripts during editing (plan mode is read-only, which blocks this)
  • Inline comments on the rendered markdown for precise, contextual feedback

Additional Context

  • Related issues: #21447 (inline suggested changes), #20386 (PR-like commenting on plans) — but neither addresses rendered markdown commenting on arbitrary files outside plan mode
  • The proposed mechanism would not require changes to the agent's permission model — it only extends the VS Code extension's commenting UI to work with any markdown file, not just plan files

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗