3 Commits

• Project selected plugin runtime by environment availability (#30093)

  ## Why
  
  Selected plugin metadata is stable, but MCP processes are live runtime
  state. They need different lifetimes:
  
  - the MCP extension caches manifest, MCP, and connector declarations for
  each stable selected root;
  - each model step projects that cached metadata through the roots that
  resolved as ready for that exact step;
  - the MCP manager is rebuilt only when that availability projection
  changes.
  
  This matches executor skills: both features consume the same resolved
  step roots instead of inferring readiness from the turn's selected
  environments.
  
  ## Behavior
  
  ```text
  E1 not ready for this step
    -> no E1 MCP servers or connectors
    -> cached plugin metadata stays in ext/mcp
  
  E1 becomes ready
    -> reuse cached metadata
    -> publish one MCP runtime containing E1 capabilities
  
  same ready roots on the next step
    -> reuse the exact runtime; no rediscovery and no MCP restart
  
  resume
    -> create new extension thread state and a new MCP runtime
  ```
  
  All model-facing consumers use the same step snapshot:
  
  ```text
  resolved selected roots
          |
          v
  extension MCP/connector projection
          |
          v
  { MCP config, connector snapshot, MCP manager }
          |
          +-> advertise model tools
          +-> build app/connector tools
          +-> execute MCP calls
  ```
  
  ## Cache contract
  
  The existing MCP extension owns a cache keyed by the full
  `SelectedCapabilityRoot`:
  
  ```rust
  let state = thread_store.get_or_init(SelectedExecutorPluginMcpState::default);
  ```
  
  The cache lives with extension thread state. Environment availability
  filters projection but does not invalidate metadata. Resume creates new
  thread state. There is no file watcher or executor generation because
  contents behind a stable environment/root are assumed stable.
  
  ## What changes
  
  - Keeps executor plugin discovery and cached metadata in `ext/mcp`.
  - Caches MCP and connector declarations together per selected root.
  - Uses the step's already-resolved capability roots, including lazy
  environments that are not turn environments.
  - Reuses the current MCP runtime when the ready-root projection is
  unchanged.
  - Uses the same step MCP manager and connector snapshot for
  model-visible tools and execution.
  - Resolves direct thread-scoped MCP requests from the current
  selected-root projection.
  
  ## Deliberately out of scope
  
  - `app/list` remains based on the latest global host-plugin state; this
  PR does not make its response or notifications thread-specific.
  - `required = true` startup semantics do not apply to delayed executor
  MCP activation.
  - No filesystem/content invalidation.
  - No transport-disconnect watcher.
  - No executor generations or environment replacement semantics.
  - No client sharing across complete manager replacements.
  
  ## Stack
  
  1. Extension-owned World State sections.
  2. Project executor skills through World State.
  3. Pin one MCP runtime to each model step.
  4. **This PR:** project selected MCP and connector state from
  extension-owned metadata.
  5. Integration coverage for selected capability availability and resume.
  
  ## Verification
  
  -
  `selected_plugin_servers_use_managed_requirements_for_the_selected_root_id`
  - The stacked integration PR covers unavailable to ready activation,
  unchanged-runtime reuse, skills, MCP tools, connector attribution, and
  cold resume.

  jif · 2026-06-26 01:36:44 +01:00
  3095ea9c3d
• Make selected plugin roots URI-native (#28918)

  ## Why
  
  Selected capability roots belong to the executor filesystem, not the
  app-server host. Converting their path strings into the host's native
  `Path` breaks whenever the two machines use different path conventions,
  such as a Windows executor behind a Unix app-server.
  
  This PR establishes `PathUri` as the selected-plugin boundary so the
  executor remains authoritative for its paths.
  
  ## What changed
  
  - Require `selectedCapabilityRoots[].location.path` to be a canonical
  `file:` URI and deserialize it directly as `PathUri`; native path
  strings are rejected.
  - Update the app-server schema, generated TypeScript, examples, and
  request coverage for the URI contract.
  - Keep selected roots, resolved plugin locations, manifest paths, and
  manifest resources as `PathUri`.
  - Inspect and read plugin roots and manifests only through the selected
  environment's `ExecutorFileSystem`.
  - Parse executor manifests with the shared URI-native parser from #29620
  instead of projecting them onto the host filesystem.
  - Enforce resource containment lexically and preserve the root URI's
  POSIX or Windows path convention.
  - Cover foreign Windows plugin roots and URI-native manifest resources.
  
  ```text
  thread/start
    selectedCapabilityRoots[].location.path = "file:///C:/plugins/demo"
                                | PathUri
                                v
                      ExecutorFileSystem
                                |
                                +--> plugin.json
                                +--> manifest resources
  ```
  
  This PR stops at the shared selected-plugin representation. The next two
  PRs remove the remaining host-path projections in the skill and MCP
  consumers.
  
  ## Stack
  
  1. #29614 — add lexical `PathUri` containment.
  2. #29620 — share URI-native manifest path resolution.
  3. **This PR** — keep selected plugin roots and resources URI-native.
  4. #29626 — load executor skills without host path conversion.
  5. #29628 — resolve executor MCP working directories without host path
  conversion.

  jif · 2026-06-23 22:51:19 +01:00
  2e69966cd8
• Discover stdio MCP servers from selected executor plugins (#27870)

  ## Why
  
  **In short:** this PR discovers MCP registrations by reading a selected
  plugin's `.mcp.json` on its executor. #27884 then resolves those
  registrations in the shared catalog.
  
  `thread/start.selectedCapabilityRoots` can select a plugin root owned by
  an executor, and Codex can resolve that package through the executor
  filesystem. MCP declarations inside the selected plugin are still
  ignored.
  
  This PR adds the source-specific discovery layer on top of the
  selected-plugin catalog boundary in #27884:
  
  ```text
  selected capability root
          |
          v
  resolve the plugin through its executor filesystem
          |
          v
  read and normalize its MCP config through the same filesystem
          |
          v
  contribute stdio registrations bound to that environment ID
  ```
  
  The existing MCP launcher and connection manager remain unchanged. MCP
  config parsing is shared with local plugins through #27863.
  
  ## What changed
  
  - Added an executor plugin MCP provider in the MCP extension.
  - Retained only the exact filesystem capability used for package
  resolution and reused it for the selected plugin's MCP config, with no
  host-filesystem fallback or unrelated process/HTTP authority.
  - Read either the manifest-declared MCP config or the default
  `.mcp.json`; a missing default file means the plugin has no MCP servers.
  - Accepted stdio servers only for this first vertical. Executor-owned
  HTTP declarations are skipped with a warning until their placement
  semantics are defined.
  - Normalized stdio registrations with the owning environment's stable
  logical ID and plugin-root working directory.
  - Resolved environment-variable names on the owning executor and
  rejected explicit local forwarding for non-local plugins.
  - Froze discovered declarations once per active thread runtime, then
  applied current managed plugin and MCP requirements when contributing
  them.
  - Carried the selected root ID, display name, and selection order into
  the catalog contribution defined by #27884.
  
  ## Behavior and scope
  
  There is intentionally no production behavior change yet. This PR
  provides the executor provider and contribution boundary, but app-server
  does not install it in this change. Existing local plugin MCP loading is
  unchanged, and no MCP process is launched by this PR alone.
  
  ## Assumptions
  
  - The selected root ID is the plugin policy identity; the manifest
  display name is presentation metadata.
  - An environment ID is a stable logical authority. Reconnection or
  replacement under the same ID does not change ownership.
  - Selected plugin packages and their manifests are trusted inputs.
  - The selected package and MCP discovery snapshot remain frozen for the
  active thread runtime.
  
  ## Follow-up
  
  The next PR installs this contributor in app-server and adds an
  end-to-end test proving that a selected plugin MCP tool launches on its
  owning executor, can be called by the model, survives an explicit MCP
  refresh, and is invisible when its root was not selected.
  
  Resume, fork, environment removal or ID changes, dynamic catalog reload,
  and executor-owned HTTP MCP placement remain separate lifecycle
  decisions.
  
  ## Verification
  
  Focused tests cover executor-only filesystem reads, missing and
  malformed config, stdio filtering and normalization, managed
  requirements, package attribution, and selection order. CI owns
  execution of the test suite.

  jif · 2026-06-15 11:52:05 +02:00
  b3c423e475