fix(copilot): share context selection across plugin processes

[mazong1123]

Summary

• Use Copilot's shared agent session ID for context selection in slash commands and the MCP bridge.
• Validate host-provided IDs while preserving the explicit override and workspace fallback.
• Guide existing users to reconnect preserved workspace-scoped selections from /neatcontext:status.
• Document fallback requirements and the long-lived MCP session-replacement limitation.

Testing

• npm test
• npm run check
• Diff coverage for all changed executable lines

[tanglearncode]

Thanks. But can you share what was the bug with more details?

[mazong1123]

Here is a minimal reproduction from the version before this PR:

User-visible reproduction

1. Create or select a context, for example demo-context.
2. Open Copilot with the NeatContext plugin enabled.
3. Run /neatcontext:use demo-context.
4. Run /neatcontext:status; it reports demo-context as connected.
5. Ask a question that causes the MCP get_context tool to run.

Actual: get_context can report no context or a previously selected context, even though the slash command reported success.

Expected: slash commands and MCP tools use the same context selection for the current session.

Deterministic developer reproduction

Start the long-lived MCP bridge from the plugin directory, then run the command CLI from a different working directory and connect a context. Before this fix, each process derived its selection scope from its own working directory, so the CLI wrote one selection file while the bridge read another. Running both processes from the same directory hides the bug.

This is a scope mismatch, not a cache or timing issue.

[tanglearncode]

Reviewed the full diff, ran the suite (66/66 green, npm run check clean), and then went and checked the PR's two factual premises against a real GitHub Copilot CLI (1.0.79-6, Windows) rather than taking them from the commit message. Summary up front, because the result cuts both ways:

The bug is real, and correctly diagnosed ✅

~/.neatcontext/plugin-sessions/ on my machine contains copilot-ws-7819cfbe611eb1b9.json, and that digest is exactly sha256(lowercase(<plugin installation directory>)). The bridge really was hashing the plugin directory while the CLI hashed the workspace. This is not a theoretical fix.

COPILOT_AGENT_SESSION_ID is also real and genuinely shared — identical value in a Copilot-spawned MCP server and in a shell-tool child, matching the id Copilot prints for --resume. The core of the fix works.

COPILOT_LOADER_PID does not exist ❌

It is in neither process. The complete COPILOT* set on 1.0.79-6 is COPILOT_AGENT_SESSION_ID, COPILOT_CLI, COPILOT_CLI_BINARY_VERSION.

So hostKey() falls back to process.ppid, which differs between the two halves (bridge → the Copilot process; CLI → a throwaway per-command shell). The whole pointer-file / drift-detection half of this PR is inert on Copilot CLI: nothing reads what the CLI writes, nothing writes what the bridge reads, and no drift warning can fire. The mid-session case the PR is named after is therefore not actually fixed on this host — and, by design, nothing reports that.

That is the one item I would not merge without resolving, or at least documenting honestly. Details inline on session.mjs:147.

Also worth fixing

• sessionIdentityIsShared() still claims a channel hostKey() will not open, and a new test pins that behaviour (session.mjs:100, copilot-session-drift.test.mjs:369).
• The 0.3.3 upgrade hint outlives the context it names, permanently — reproduced (neatcontext-cli.mjs:112).
• /neatcontext:status carries a second, non-waiting copy of the drift check that will produce false positives once host keys line up (neatcontext-cli.mjs:261).
• pruneHostPointers() is never called on Copilot, and the sweep skips the new .tmp files (neatcontext-cli.mjs:82, shared/core/host-session.mjs:337).
• Two README claims the code does not deliver (README.md:53, README.md:60).

The design — one pointer file per host process, promoted into shared/core/ with a per-adapter pid provider, atomic temp-write + rename — is the right shape, and the reasoning about not keeping a global list of every host's pid variable is correct and worth having written down. The problem is that the specific variable the Copilot adapter was built around isn't there.

Probe method, if you want to reproduce: register a stub MCP server via --additional-mcp-config that dumps process.cwd()/ppid/env on startup, and have the prompt run a shell command that does the same. Note that a server registered that way gets the workspace as its cwd — only plugin-provided servers get the plugin directory, which is why the on-disk digest above is the better evidence.

[mazong1123]

Thanks for the detailed review and for verifying the behavior on a current Copilot CLI build.

I narrowed the PR to the behavior we can verify:

• COPILOT_AGENT_SESSION_ID is now the shared selection scope for slash commands and the MCP bridge.
• NEATCONTEXT_SESSION_ID still takes precedence.
• The workspace digest remains the fallback when no host session ID is available.
• A regression test starts the CLI and bridge in different working directories and verifies that they share one selection; a different agent session remains isolated.

I removed the host-pointer and drift-detection design entirely. That also removes the unsupported COPILOT_LOADER_PID assumption and the related cleanup, race, upgrade-hint, warning-channel, temp-file, and documentation concerns raised in the inline comments. The Claude/Codex/shared-core changes are no longer part of this PR.

Current validation: full suite passes (456 tests), npm run check passes, and all changed executable lines have diff coverage.

[tanglearncode]

Re-reviewed at 49151be. This is a much better PR, and it resolves the blocker from my previous review.

Reverting the pointer-file machinery was the right call. What is left is the part that was actually verified against a real Copilot CLI — COPILOT_AGENT_SESSION_ID exists, is published to both the MCP server and the slash-command process, and matches the id Copilot prints for --resume — and none of it now depends on COPILOT_LOADER_PID, which does not exist on Copilot CLI 1.0.79-6. The title and description were updated to match the narrowed scope, which I appreciate: the PR no longer promises to fix the mid-session case it cannot.

Verification on this branch: npm run check clean; tests/copilot-plugin.test.mjs 14/14; full suite 456/456 across three consecutive runs. (My first full run reported 455/456, but I had not captured the reporter output and three subsequent runs were clean, so I cannot name the test — most likely contention with a npm run check I had just run. Mentioning it only so a CI hiccup is not a surprise.)

One item before merge

Existing Copilot users lose their connected context with no signal. Reproduced; details inline on session.mjs. The old copilot-ws-<digest> selection is not deleted, it simply stops being read — and revision 1's upgrade hint was removed along with machinery it did not depend on. Restoring the hint, or at minimum a README line, is the difference between a silent disappearance and "reconnect it once."

Smaller points

• explicitId no longer validates, and a host-supplied value now becomes a path segment (session.mjs:39).
• The mid-session limitation is undocumented, and the suite no longer covers it at all (session.mjs:9, copilot-plugin.test.mjs:593).
• The README fallback sentence promises more than the fallback delivers on the host shape that caused this bug (README.md:54).

Everything above is small. With the upgrade note added I would be happy to see this merged.

[mazong1123]

Thanks for the follow-up review. I addressed the remaining items without reintroducing the pointer-file design:

• /neatcontext:status now detects a preserved workspace-scoped selection after upgrade, verifies that its context still exists, and tells the user how to reconnect it for the current session. It never deletes or migrates the old file.
• Host-provided COPILOT_AGENT_SESSION_ID values are validated before they become selection filenames. The existing NEATCONTEXT_SESSION_ID override keeps its prior behavior for compatibility.
• The README now qualifies the workspace fallback, documents the upgrade behavior, and states that an MCP process does not detect a session replaced underneath it.
• Tests cover unsafe host IDs, the upgrade hint, suppression after reconnecting, suppression after context deletion, cross-working-directory agreement, and session isolation.

Validation remains green: 457 full-suite tests, npm run check, and complete diff coverage.

[tanglearncode]

LGTM. Thanks!