Live (directory-marketplace) plugins are invisible to the app's global agent lookup and to session resume, while the CLI resolves them correctly

Affected version or release

Copilot app (github.exe) 1.1.15 · bundled CLI binary in ...\github-copilot-sdk\cli\1.0.83-5\, --version reports 1.0.84-1 · Windows 11 Enterprise 10.0.26200

Installation context

Local desktop install, single user. Custom agents contributed by a CLI plugin registered through a directory-source marketplace (a local folder), which the CLI classifies as a "live" plugin. No org/enterprise agent configuration involved.

~/.copilot/settings.json:

"extraKnownMarketplaces": {
  "my-marketplace": {
    "source": { "source": "directory", "path": "E:\\vault\\api\\marketplace" }
  }
},
"enabledPlugins": { "my-plugin@my-marketplace": true }

copilot plugin list reports these under "Live Plugins (loaded from a local marketplace directory, never copied)", and ~/.copilot/config.json → installedPlugins correctly contains no entry for them.

What happened?

CLI 1.0.81 introduced "live" loading for plugins in a directory-source marketplace: they load from their real directory and are never copied. This is documented in the CLI plugin reference, under "copilot plugins update options":

Note
Path-sourced plugins in a local (directory-source) marketplace load live from their real directory—editing one takes effect on /restart or in a new session, with no copilot plugin update needed.

This works correctly in the CLI. The desktop app, however, does not resolve live plugins on two code paths:

1. list_global_agents when project_path is null — live plugins contribute zero agents. Any non-null path, including a directory that is not a project at all, resolves them correctly.

2. session.resume — resuming a session whose agent is provided by a live plugin fails with Custom agent '<plugin>:<agent>' not found, even though the app passes the session's real cwd and sets enable_config_discovery=true.

The same plugin registered as an installed copy works on both paths. The CLI resumes the very same session successfully while the app cannot, which isolates the defect to the app layer rather than the engine.

Net effect: with plugins registered only as live, the Settings → default agent picker is empty, the new-session agent selector shows no custom agents, and every existing session bound to a plugin agent becomes unopenable in the app ("Session Unavailable"). In my case that is ~316 sessions.

Steps to reproduce

Setup. Register a directory-source marketplace containing two plugins, then enable both. Install one of them additionally as a copy (copilot plugin install <path>) to act as a control. Confirm via copilot plugin list that one appears under "Installed plugins" and the other only under "Live Plugins".

Issue 1 — project_path: null excludes live plugins

1. Query the app's list_global_agents handler with project_path: null.
2. Repeat with project_path set to various directories.

project_path	agents returned	live plugin's agents present?
null	5	❌ NO
C:\Windows\Temp (not a project — no git, no .github)	7	✅ YES
C:\Users\<user> (not a project)	7	✅ YES
D:\ws\myproject (a real project)	7	✅ YES

The installed control plugin's 5 agents appear in all four cases. The live plugin's 2 agents appear in every case except null.

The trigger is therefore not project validity — C:\Windows\Temp is not a project by any definition and is sufficient. It is specifically that when project_path is null, live/directory-marketplace resolution is skipped and only config.json → installedPlugins contributes. I confirmed the direction of causation by flipping a single plugin between live and installed and re-querying, holding the other constant.

Consequence: Settings → default agent has no project context and passes null, so it shows no custom agents from live plugins.

Issue 2 — session.resume cannot see live plugins

3. Create a session that uses an agent from the live plugin, and let it persist.
4. Restart the app and attempt to open that session.

From the app log:

17:40:12  INFO  resuming session session_id=<session-id-A> cwd="D:\ws\myproject"
17:40:15  INFO  resuming session session_id=<session-id-A> cwd="D:\ws\myproject"
                session_type=Project enable_config_discovery=true
17:40:18  WARN  failed to resume session session_id=<session-id-A>
                error=RPC error -32603: Request session.resume failed with message:
                session construction failed: Custom agent 'my-plugin:my-agent' not found

Note the app does pass the correct project cwd and does enable config discovery, and still fails. So this is not simply Issue 1 leaking through a null path — session construction appears to use a plugin loader that does not consult live plugins at all.

5. Resume the same session ID from the CLI, with the plugin still live-only:

copilot --resume=<session-id-A> --available-tools=view --no-ask-user -p "Reply with only the word: CLI-REACHED"
→ CLI-REACHED

The app and CLI share one session store (~/.copilot/session-store.db), so this is the same session record, not a lookalike. CLI succeeds, app fails, same moment, same configuration.

Expected behavior

A plugin that is enabled and loadable — whether installed or live — should contribute its agents on every resolution path, including list_global_agents with project_path: null and during session construction on resume. Registration style should not change which agents exist.

Actual: live plugins are resolved only when a non-null path is supplied, and never during session construction.

Additional context

A same-process contradiction. From an earlier app run, two log lines 11 milliseconds apart in the same process:

05:06:26.259  INFO  listed global agents agent_count=7 project_path="D:\ws\myproject" elapsed_ms=4921
05:06:26.270  WARN  failed to resume session session_id=<session-id-B>
                    error=… Custom agent 'my-plugin:my-agent' not found

The session being resumed has D:\ws\myproject as its own workspace root — the exact path that had just resolved 7 agents including the one reported missing. The agent was demonstrably discoverable by the app's own lookup at that path, 11 ms earlier, in the same process, and session construction still could not find it.

Registration type is the only variable. I ran this in both directions on one machine, changing nothing else:

Registration	Settings picker	App session resume
Installed copy	✅ all agents listed	✅ session resume flow completed
Live only	❌ empty	❌ Custom agent … not found

Same agent files, same identifiers, same content, same app build.

Workaround, and why it is unsatisfying. Install the plugin as a copy (copilot plugin install <path>, a documented install format) instead of relying on live resolution. But:

1. It discards the benefit live loading exists to provide — edits then require a reinstall to take effect.
2. copilot plugin install <local path> prints: "Direct plugin installs (repos, URLs, local paths) are deprecated. Only plugin@marketplace installs will be supported in a future release." For a directory-source marketplace, plugin@marketplace produces exactly the live state that is broken here. So the currently-working route is deprecated and the intended future route does not work on this path — worth resolving before direct installs are removed.

A related resolution ambiguity. copilot plugin update <bare-name> resolves to the live registration even when that registration is disabled and an installed copy of the same name exists, reporting "is always loaded live … there is nothing to update" and silently doing nothing. Bare-name resolution appears to prefer the marketplace entry over the direct install in several commands (uninstall behaves the same way), which makes it easy to operate on the wrong registration without noticing.

Possibly related

• github/app#3314 — directory-source marketplace plugins silently pruned from installedPlugins while enabledPlugins still lists them enabled. Same enabledPlugins-true / installedPlugins-empty split; may share a root cause.
• github/copilot-cli#4608 — hooks from a live path-sourced plugin do not run in a resumed session; regression bisected to 1.0.81, the same release that introduced live loading. Same bug shape, different component.
• github/copilot-cli#4629 — plugin-contributed hooks dropped on the resume path.
• github/copilot-cli#4592 — Plugin activation [agents]: plugins=6, loaded=0, producing the same Custom agent … not found error string.

_{Paths, plugin names, agent names and session IDs in this report are genericized; the reproduction does not depend on the originals.}

Start by reproducing the two reported paths: query list_global_agents with project_path null and resume a session whose agent comes from a live directory-marketplace plugin. Compare those results with a non-null project path and an installed copy, using the app logs and the CLI commands in the report. Done means live plugins appear in global agent lookup and the same session resumes successfully in the app.