Identifier continuity treated as state continuity

Description

This weakness sits at the boundary between two facts a continuation, resume or reattachment step can quietly collapse into one. The first fact is that a caller's request named a specific identifier, a session id, a conversation id or a similar handle, and the same identifier came back once the operation completed. The second, entirely separate fact is that the state the identifier names, the actual conversation history, the actual authenticated session, the actual resource, was located and carried forward by whichever system responded. An identifier a caller supplied, or that the caller previously received and is now presenting again, is not evidence of the second fact produced independently of the very claim being verified: the same string appearing in the response a caller expects to see is exactly what a system with no matching state at all, or with different state entirely, would also produce if it simply echoed the request or minted a fresh replacement under the same name. This differs from a claimed authorization accepted without verification, AEW-007: there, an actor states in words that it holds authority nothing checks; here, nobody makes a false claim in words at all, and the gap opens because a structural value, an identifier, is asked to serve as both the caller's own request and the system's own proof, when nothing about it changes depending on which one it actually is. It differs from an authentication failure converted into an accepted authority state, AEW-016, and from a failed resource resolution inheriting the trust of its apparent path, AEW-017: both of those concern a check that exists, runs and fails, whose failure is then wrongly treated as a pass; here the evidence available does not establish that any check ran or failed at all, only that whatever happened produced no explicit error while the identifier stayed the same, a different and, for a caller, harder to distinguish shape of gap, since the absence of a failure signal is not evidence a check succeeded. It differs from a partial context republication restoring an obsolete mandate as active, AEW-019: there, one system's own internal maintenance process substitutes an obsolete branch while a session identifier it minted and controls stays constant throughout, a same process bookkeeping failure; here the identifier crosses two independently built and independently operated execution surfaces, potentially even different builds of the same underlying executable, so there is no shared internal bookkeeping to point to, only the fact that identifier equality between a request and a response was treated as sufficient without either side establishing where the state itself actually came from.

The authority gap

The continuity evidence required is an assertion, independent of the request that names it, that specific existing state was located and carried forward. The continuity evidence presented is the same identifier the caller supplied or already held, which is not independent of the claim it is being asked to prove.

Failure conditions

• A caller requests that a system continue, resume or reattach to state it names by a specific identifier, one the caller itself supplied, allocated or previously received.
• The system's response carries the identical identifier forward without independently asserting, through a value or channel the caller's own request did not supply, that the specific state named actually exists and was located.
• No distinct signal in the response contract separates continuity that was independently confirmed from an identifier that was merely accepted, echoed or freshly reissued under the same name.
• The absence of an explicit failure is available to be read as confirmation of continuity, though the response contract does not actually distinguish the two outcomes.

Consequences shown by the evidence

• A resumed or continued operation proceeds on absent, substitute or unverified state while every caller and downstream system involved continues to treat the operation as a genuine continuation, because nothing in the exchange distinguished the two outcomes.
• Detecting the gap depends entirely on a caller independently testing for content only the genuine state would contain, since no protocol level signal marks the divergence on its own.

Detection signals

• A resume, continuation or reattachment operation completes and returns the requested identifier even when that identifier is deliberately pointed at unrelated, unknown or absent underlying state.
• The response contract defines error handling for a malformed or unrecognized identifier but no distinct outcome for a well formed identifier whose named state could not be independently confirmed.
• A client or downstream integration treats call success and identifier equality as sufficient checks, with no further verification step exposed to it.

Known examples

• GitHub issue agentclientprotocol/claude-agent-acp#1019, opened 21 August 2026 by user taras and, per this record's own direct fetch on 7 September 2026, still open with no comments and no linked fix. The issue reports that resuming a native claude session, started with claude --session-id, through the Agent Client Protocol adapter, @agentclientprotocol/claude-agent-acp 0.70.0, bundling @anthropic-ai/claude-agent-sdk 0.3.232 and, inside that SDK, Claude Code 2.1.232, against a native host running Claude Code 2.1.235 and ACP client acpx 0.12.0, accepts a client allocated session UUID, completes the ACP turn, and returns that identical UUID, while a marker word planted only in the native session's own prior history through that same UUID is not recovered when a marker free prompt asks for it, and no resource_not_found or other explicit continuity failure is raised. The issue's own reproduction is precise: allocate a UUID client side, create native history containing the marker under that UUID with claude --session-id, resume the same UUID through ACP from the same working directory, then ask a marker free prompt requiring its recall. The issue states plainly, and this record preserves without narrowing, what the observation does and does not establish: the same requested and returned identifier does not prove the same conversation history was loaded, and the native history's absence from the resumed turn does not itself prove the adapter created a new session, only that whatever state the turn drew on was not that specific native history. The issue's own leading explanation, an executable or version mismatch between the SDK bundled Claude Code build and the native CLI build that created the session, is offered by its author explicitly as an unproven hypothesis, not a finding. GitHub issue taras/executable.md#770, opened 7 September 2026 by the same reporter and, confirmed by this record's own direct fetch, explicitly naming and referencing issue 1019, documents a downstream project's reaction to the identical pattern: attempting a native to ACP continuation, the same adapter 0.70.0, against native Claude Code 2.1.263, and finding that the ACP handle a session resume call returns carries a backendSessionId equal to the caller's own previously retained UUID with no independently asserted agentSessionId alongside it. The reporting project's own tooling, on the stated basis that identifier equality alone is not independent continuity evidence, refuses to send any prompt into that handle; the adapter attachment returned, no prompt was sent, and the native transcript this record can confirm from the issue text was left unchanged. Neither issue carries a maintainer response, a linked fix, a formally assigned vulnerability identifier, or any report of active exploitation as of this record's own verification; whether the version skew hypothesis in issue 1019 is the actual mechanism, and what specifically produced the absent history, remain unestablished.

Recorded instances

• AEV-2026-0044 claude-agent-acp resumes a native Claude session by identifier without independently confirming its history loaded candidate Observed

Related Intelligence Records

The published Moona Intelligence Records whose evidence establishes this weakness.

• The Session ID Matched. The Conversation Did Not.