Problem
Consumers that manage sessions in a shared PTY registry cannot safely authorize mutation, kill, or removal from a session name and mutable tags alone. Names can be reused, and current metadata such as createdAt is not an immutable authenticated incarnation token. A durable local receipt can therefore accidentally authorize a replacement session after name reuse.
This prevents a consumer from satisfying a basic compare-and-act contract:
- create a session;
- persist independent ownership evidence for that exact creation;
- later mutate/kill/remove only if the currently named session is still that creation.
Proposed capability
Expose an immutable, opaque session incarnation ID minted by PTY at creation and returned on reads. Add conditional forms of action-bearing operations (at least tag update, kill, and remove) that fail if the expected incarnation no longer matches.
Conceptually:
create(name) -> { name, incarnation }
get(name) -> { name, incarnation, ... }
updateTags(name, expectedIncarnation, patch)
kill(name, expectedIncarnation)
remove(name, expectedIncarnation)
The identifier should be stable for one create occurrence, change on name reuse, and not be writable through ordinary metadata/tag APIs.
Why this belongs in PTY
A client-generated nonce stored as a tag is circular because the same mutable metadata is being authorized. A registry root or reusable session name establishes scope, not lifecycle ownership. Only the registry can authoritatively bind an action to the current physical session incarnation without a time-of-check/time-of-use race.
This would let higher-level tools maintain durable ownership receipts and fail closed for unadopted or replaced sessions.
Problem
Consumers that manage sessions in a shared PTY registry cannot safely authorize mutation, kill, or removal from a session name and mutable tags alone. Names can be reused, and current metadata such as
createdAtis not an immutable authenticated incarnation token. A durable local receipt can therefore accidentally authorize a replacement session after name reuse.This prevents a consumer from satisfying a basic compare-and-act contract:
Proposed capability
Expose an immutable, opaque session incarnation ID minted by PTY at creation and returned on reads. Add conditional forms of action-bearing operations (at least tag update, kill, and remove) that fail if the expected incarnation no longer matches.
Conceptually:
The identifier should be stable for one create occurrence, change on name reuse, and not be writable through ordinary metadata/tag APIs.
Why this belongs in PTY
A client-generated nonce stored as a tag is circular because the same mutable metadata is being authorized. A registry root or reusable session name establishes scope, not lifecycle ownership. Only the registry can authoritatively bind an action to the current physical session incarnation without a time-of-check/time-of-use race.
This would let higher-level tools maintain durable ownership receipts and fail closed for unadopted or replaced sessions.