SessionMetadataSnapshot.AlreadyInUse is always false for SDK-resumed sessions (never reflects concurrent use by another process)

[BenPryor]

Summary

session.Rpc.Metadata.SnapshotAsync() returns a SessionMetadataSnapshot whose AlreadyInUse is always false when a session is opened through the SDK — even when the same session is concurrently held open by a different live process. The documented contract says this field should be true "when the session was detected to be in use by another process."

The in-use information clearly exists at the time of the call (a live per-process lock file is present on disk in the session directory), but it is not reflected in the snapshot. This affects both a default resume and a resume with SuppressResumeEvent = true.

Environment

• SDK: GitHub.Copilot.SDK (.NET) v1.0.1
• Bundled Copilot CLI: 1.0.63 (managed automatically by the SDK)
• OS: Windows
• Note: the root cause appears to be server-side (Copilot CLI), since the .NET client deserializes alreadyInUse straight from the session.metadata.snapshot RPC response. The same field exists in every language SDK (alreadyInUse / AlreadyInUse), so all clients are likely affected.

Expected behavior

Per the generated contract for SessionMetadataSnapshot.AlreadyInUse:

True when the session was detected to be in use by another process at construction time. Local consumers may surface a confirmation prompt before fully attaching. Always false for new sessions.

So when a session is resumed while another live process is holding it, AlreadyInUse should be true.

Actual behavior

AlreadyInUse is false in that scenario.

Minimal reproduction

Self-contained: two CopilotClient instances in one program (each spawns its own CLI server process, so the second one is genuinely "another process" relative to the first).

using GitHub.Copilot;

#pragma warning disable GHCP001 // SnapshotAsync is experimental

// Client A creates a session, sends one message so it persists to disk,
// then stays alive (its CLI server keeps holding the session).
await using var holder = new CopilotClient();
var held = await holder.CreateSessionAsync(new SessionConfig
{
    OnPermissionRequest = PermissionHandler.ApproveAll,
});
var sessionId = held.SessionId;
await held.SendAndWaitAsync(new MessageOptions { Prompt = "Reply with exactly: OK" });

// Client B (independent client + CLI server) resumes the SAME session
// using the DEFAULT resume path, then reads the snapshot.
await using var probe = new CopilotClient();
await using var resumed = await probe.ResumeSessionAsync(sessionId, new ResumeSessionConfig
{
    OnPermissionRequest = PermissionHandler.ApproveAll,
});

var snapshot = await resumed.Rpc.Metadata.SnapshotAsync();
Console.WriteLine($"AlreadyInUse = {snapshot.AlreadyInUse}");   // prints False; expected True

Observed output

[holder] Created session: f5fdd147-8928-4759-b74c-fd3ffc2b469b
[disk] events.jsonl persisted: True (27817 bytes)
[disk] Lock files present (holder still alive): inuse.20772.lock
[probe] snapshot.AlreadyInUse = False   (EXPECTED: True — held by [holder] process)

While probe calls SnapshotAsync(), the session directory
~/.copilot/session-state/f5fdd147-.../ contains inuse.20772.lock, and PID 20772
(the holder's CLI server) is alive — i.e. the session is demonstrably in use by another
process, yet the snapshot reports AlreadyInUse = False.

Supporting evidence

• The session directory contains a per-process lock file named inuse.<pid>.lock whose contents are the owning process PID. During the repro this file exists and its PID is a live process, so the "in use by another process" condition is objectively true at snapshot time.
• The behavior is identical with SuppressResumeEvent = true and with the default resume, so it is not a side effect of suppressing the resume event.

Hypothesized root cause

On the SDK resume path, the runtime does not surface the in-use/lock-detection result onto the metadata snapshot — AlreadyInUse is left at its default (false). The underlying data is available (the lock files are on disk and detection runs), so this looks like the computed value simply isn't propagated to the snapshot for SDK-initiated resumes, whereas a brand-new session correctly reports false.

Test coverage gap / suggested fix

The existing e2e tests assert AlreadyInUse == false only for a freshly-created session, which is correct per the "Always false for new sessions" clause, but none cover a session that is concurrently in use:

• dotnet/test/E2E/RpcSessionStateE2ETests.cs → Assert.False(initialSnapshot.AlreadyInUse);
• go/internal/e2e/rpc_session_state_e2e_test.go
• nodejs/test/e2e/rpc_session_state.e2e.test.ts → expect(initialSnapshot.alreadyInUse).toBe(false);

Suggested additions:

1. Populate alreadyInUse on the snapshot from the same in-use detection used elsewhere, on the SDK resume path.
2. Add an e2e test: create + hold a session in one client, resume it from a second client, and assert the second client's snapshot reports AlreadyInUse == true.

[github-actions]

Investigation findings

Verdict: Confirmed bug — SessionMetadataSnapshot.AlreadyInUse is never true for SDK-resumed sessions, contrary to the documented contract.

What I investigated

SDK-side code paths:

• dotnet/src/Generated/Rpc.cs — SessionMetadataSnapshot.AlreadyInUse is a plain deserialized bool, populated verbatim from the JSON-RPC response ("alreadyInUse" field). No SDK-side transformation.
• Same field exists in all other languages: go/rpc/zrpc.go (AlreadyInUse bool), nodejs/src/generated/rpc.ts, python/copilot/generated/rpc.py, rust/src/generated/api_types.rs, java/src/generated/java/.../SessionMetadataSnapshotResult.java.
• SessionStartData.AlreadyInUse and SessionResumeData.AlreadyInUse (event stream) also exist and are separate from the RPC snapshot path.

E2E tests:

• dotnet/test/E2E/RpcSessionStateE2ETests.cs:294 — Assert.False(initialSnapshot.AlreadyInUse) (new session only ✓)
• nodejs/test/e2e/rpc_session_state.e2e.test.ts:328 — expect(initialSnapshot.alreadyInUse).toBe(false) (new session only ✓)
• go/internal/e2e/rpc_session_state_e2e_test.go:503 — checks !initial.AlreadyInUse (new session only ✓)
• No snapshot YAML in test/snapshots/rpc_session_state/ contains alreadyInUse, confirming no "already in use" scenario is ever exercised.

What I found

The SDK is a pure pass-through client: it deserializes alreadyInUse straight from the CLI's session.metadata.snapshot JSON-RPC response and exposes it unchanged. There is no SDK-side code that could suppress or override this field.

The root cause is therefore server-side (Copilot CLI): the CLI is not setting "alreadyInUse": true in the snapshot response when it detects an active lock file for the session. The documented contract ("True when the session was detected to be in use by another process at construction time") is not being upheld for the snapshot RPC path, even though the lock file is verifiably present on disk at the time of the call.

Test coverage gap (confirmed)

All existing E2E tests only assert alreadyInUse == false for freshly-created sessions, which is trivially correct. No test ever resumes a concurrently-held session and checks that the field is true. This gap means the regression has gone undetected.

Summary

This is a genuine bug: the CLI's session.metadata.snapshot handler does not propagate the lock-detection result into the response payload for resumed sessions. The field defaults to false and is never overridden, even when an inuse.<pid>.lock file is present and its PID is alive. The SDK itself needs no changes beyond adding E2E coverage once the CLI fix lands.

Generated by Bug Handler for issue #1749 · sonnet46 1.6M · ◷