#265 [Feat] Live Context: follow the GUI selection from the MCP server (v5.2)

[Anonymous]

Originally created by: Avazbek22

Idea

Connect the GUI and the MCP server so the human curates context visually and the agent consumes it live: open DevProjex, toggle ignore checkboxes, apply a filter, select files in the tree — and the MCP server serves exactly that selection to the AI right now. In the chat you just say "take the context and look at this bug"; the model sees precisely what is selected on screen at that moment.

This is a direction sketch, not a finished spec. It is the strongest v5.2 candidate because it builds on an asset no other packing MCP server has: a desktop context curator with a live tree, exclusion toggles, and token metrics. It also completes the product line "you control what the AI sees" in the most literal way — the ceiling for the agent becomes the user's live on-screen selection.

How it could work

User in GUI:  unchecks Tests/, applies a filter, selects 12 files
Agent:        pack_context(...)            (server started with --follow-gui)
Server:       asks the running GUI over IPC for a snapshot of the effective selection
              -> builds the pack from exactly those 12 files, mandatory redaction as always
Next call:    user changed the selection meanwhile -> agent sees the new state

• The snapshot is taken per tool call; the plan fingerprint already tells the agent when the selection changed between calls.
• "Effective selection" needs no new definition: it is what the GUI would export right now with its own export action — one source of truth, no parallel state.
• The security model is unchanged and arguably strengthened: secret redaction stays mandatory and schema-free, agent parameters keep narrowing-only semantics, and the baseline is now the human's live choice instead of a static configuration.

What already exists

• Desktop Control IPC: the CLI already drives a running GUI instance (devprojex ui preview open, ui filter set, ui search set, ...) with instance addressing (--instance, --project) and bounded timeouts (Docs/Desktop-Control.md). Today the pipe is command-shaped (CLI -> GUI "do"); this feature adds the query direction (MCP -> GUI "what is selected?").
• The MCP server already has the startup-flag pattern for opt-in behavior (--hide-private-data, --allow-remote); --follow-gui follows the same shape.

Possible phases

1. Core: devprojex mcp --follow-gui — the server resolves the effective selection from the running GUI for pack_context / analyze / get_tree. This alone is the demo: change a checkbox, the next agent call sees it.
2. Trust in both directions: a GUI indicator showing that an MCP session is attached and what the agent last requested, so the human sees agent activity, not only the agent seeing the human's selection.
3. TUI parity over the same IPC pattern.

Open questions to settle before implementation

• Lifecycle: GUI not running, project mismatch, several windows — error codes and instance-selection rules for the agent (DPX-MCP-*, clear retry guidance). Does --follow-gui require --root to pin which project may be followed, or does the followed GUI instance define the root?
• Snapshot scope: selection tree + git axis + exclusion toggles are clearly in; do transformation toggles (compress/strip) and the active preview filter/search also travel, or only the file set?
• Combination rules: what do explicit per-call paths/globs mean on top of a followed selection (presumably the usual narrowing), and is profile rejected in this mode?
• Consistency: a pack is built from one snapshot — confirm the snapshot is atomic on the GUI side while the user keeps clicking.
• Race with GUI shutdown mid-call; timeout behavior mirrors ui command timeouts.
• Whether the same IPC query should also serve the CLI (e.g. devprojex export context --follow-gui) for surface parity.

Notes

• Not for v5.1 — this is a full feature cycle of its own.
• No redaction controls appear in any schema; --follow-gui changes where the baseline comes from, never what redaction does.