Agent cancels pending manual approvals automatically and treats then as unapproved instead of waiting.

This issue highlights an important authorization-state boundary:

approval still pending
≠ approval denied
≠ request cancelled
≠ alternative execution authorized

A manual approval request should be represented as durable runtime state rather than a transient conversational prompt.

A possible approval record:

{
"schema_version": "approval-request/v0.1",
"approval_id": "approval-184",
"trajectory_id": "repository-task-001",
"continuation_id": "thread-009",
"requester": {
"session_id": "codex-thread-123",
"agent_id": "codex-root"
},
"action": {
"effect_class": "PROCESS_EXECUTION",
"command": "npm install",
"action_digest": "sha256:..."
},
"status": "PENDING",
"requested_at": "2026-06-24T19:41:00Z",
"expires_at": null,
"resolution": null
}

A useful lifecycle could be:

CREATED
→ PRESENTED
→ PENDING
→ APPROVED | DENIED | EXPIRED | CANCELLED_BY_USER | INVALIDATED

The central invariant would be:

«Only an authorized approver, an explicit expiry policy, or a valid context invalidation event may resolve a pending approval.»

The requesting agent should not be able to convert:

PENDING → DENIED

or:

PENDING → CANCELLED

merely because it prefers not to wait.

Another important invariant:

«Cancelling one approval request must not imply permission to execute a semantically equivalent action through another tool or command.»

For example:

approval requested for:
npm install package-x

request cancelled

agent attempts:
npx package-x
curl installer | sh

These alternatives should be correlated by semantic effect and remain blocked if they require the same authority.

A resolution event could look like:

{
"approval_id": "approval-184",
"status": "APPROVED",
"resolved_by": {
"actor_type": "USER",
"actor_id": "local-operator"
},
"resolved_at": "2026-06-24T19:44:18Z",
"approved_action_digest": "sha256:...",
"scope": {
"single_use": true,
"workspace": "project-alpha"
}
}

The action executed afterward should reference that exact approval:

{
"event_type": "PRE_EFFECT",
"effect_class": "PROCESS_EXECUTION",
"action_digest": "sha256:...",
"approval_ref": "approval-184",
"decision": "ALLOW"
}

If the command, arguments, target, workspace, or policy changed, the digest would no longer match and a new approval would be required.

The runtime should also distinguish waiting from agent failure:

turn waiting for approval
→ WAITING_FOR_USER

not:
→ FAILED
→ DENIED
→ COMPLETED

This state should survive:

• TUI refresh;
• temporary disconnection;
• compaction;
• thread resume;
• application restart.

A deterministic conformance fixture could test:

1. approval remains "PENDING" while the user has not responded;
2. agent cannot resolve its own request;
3. waiting turn does not report failure or denial;
4. explicit user denial produces "DENIED";
5. explicit user cancellation produces "CANCELLED_BY_USER";
6. expiry occurs only when an expiry policy is configured;
7. changed command digest requires a new approval;
8. equivalent action through another tool remains blocked;
9. restart and resume preserve the pending request;
10. one-time approval cannot be replayed for a second execution.

Related LS work:

• evidence and authorization gates:

https://github.com/safal207/LS/issues/595

• commit-before-effect:

https://github.com/safal207/LS/issues/596

• deterministic replay:

https://github.com/safal207/LS/issues/597

• recovered continuation state:

https://github.com/safal207/LS/pull/651

Would a small vendor-neutral "ApprovalRequest" and "ApprovalResolutionEvent" conformance fixture help test durable pending state, action binding, agent self-cancellation prevention, and resume behavior?

The bug here is not just timeout behavior. It is an authorization-state bug: pending approval is being collapsed into missing approval.

Once a manual approval prompt is presented, the request should become durable runtime state with an explicit lifecycle:

1. requested;
2. presented;
3. pending;
4. approved, denied, expired, user_cancelled, agent_cancelled, or invalidated.

Only the user, an explicit expiry policy, or a real context invalidation should be allowed to resolve pending into a terminal state. The requesting agent should not be able to convert pending into denied or cancelled by terminating the underlying tool call.

I would make the execution invariant equally strict:

• while approval is pending, the turn is waiting_for_user, not failed, denied, or complete;
• a terminal resolution records who or what resolved it;
• approved execution binds back to the original approval id and action digest;
• changed command, arguments, workspace, target, or policy requires a new approval;
• cancelling or expiring one approval does not authorize an equivalent side effect through another command;
• restart, compaction, or resume preserves the pending approval or reports an explicit lost-state error.

The regression test can be small: open an approval prompt, leave it pending longer than the current timeout window, and prove the agent cannot dismiss it, cannot report denial, and cannot continue the same authority path until the user or an explicit expiry policy resolves it.

@rpelevin Yes — I think that’s the right framing: this is an authorization-state bug, not just timeout handling.

pending approval should be a first-class durable runtime state, not something that can collapse into “missing approval” when the requesting tool call exits or the agent retries around it.

The invariant I’d want is:

• pending keeps the turn in waiting_for_user;
• only the user, an explicit expiry policy, or a real context invalidation can resolve it;
• agent-side cancellation of the underlying call must not silently convert that pending authority path into denied / missing / retryable approval;
• restart / compaction / resume must either preserve the pending approval state or surface an explicit lost-state error.

I’d also bind the eventual approval back to the original approval id + action digest, so a later “equivalent” command can’t spend the old pending/approved authority after the command, args, workspace, target, or policy surface changed.

So the core distinction for me is exactly the one you called out:

pending approval ≠ missing approval

I would model this as an approval-transition ownership problem.

A pending manual approval should not be controlled by the same lifecycle as the tool process being approved.

The key boundary is:

pending approval
does not imply
agent-owned cancellable process

Let:

approval_request_hash = H(
approval_id,
tool_call_id,
command_or_patch_hash,
writable_scope,
reviewer_id,
approval_policy,
created_at
)

terminal_state must be one of:

user_approved
user_rejected
user_cancelled
agent_cancelled
expired
connection_lost

The agent should not be allowed to collapse these states into:

approval_not_granted

Minimal verifier:

def resolve_approval_state(approval):
terminal_state = approval.get("terminal_state")
actor = approval.get("terminal_actor")

allowed_terminal_states = {
"user_approved",
"user_rejected",
"user_cancelled",
"agent_cancelled",
"expired",
"connection_lost",
}

if terminal_state not in allowed_terminal_states:
return {
"decision": "approval_pending_or_invalid",
"reason": "unknown_terminal_state"
}

if terminal_state == "agent_cancelled":
return {
"decision": "do_not_report_as_user_rejected",
"reason": "agent_cancelled_pending_approval"
}

if terminal_state == "expired":
return {
"decision": "do_not_report_as_user_rejected",
"reason": "approval_expired"
}

if terminal_state == "connection_lost":
return {
"decision": "do_not_report_as_user_rejected",
"reason": "approval_connection_lost"
}

return {
"decision": terminal_state,
"reason": None
}

Minimal negative controls:

[
{
"case": "agent_terminates_pending_approval",
"approval": {
"terminal_state": "agent_cancelled",
"terminal_actor": "agent"
},
"expected": "do_not_report_as_user_rejected"
},
{
"case": "approval_timeout_reported_as_rejection",
"approval": {
"terminal_state": "expired",
"terminal_actor": "system"
},
"expected": "do_not_report_as_user_rejected"
},
{
"case": "connection_lost_reported_as_rejection",
"approval": {
"terminal_state": "connection_lost",
"terminal_actor": "transport"
},
"expected": "do_not_report_as_user_rejected"
}
]

Minimal positive controls:

[
{
"case": "user_explicitly_rejects",
"approval": {
"terminal_state": "user_rejected",
"terminal_actor": "user"
},
"expected": "user_rejected"
},
{
"case": "user_explicitly_approves",
"approval": {
"terminal_state": "user_approved",
"terminal_actor": "user"
},
"expected": "user_approved"
}
]

The important distinction is:

the user did not approve
does not imply
the user rejected or failed to approve.

If the agent cancels the pending tool call, the terminal state should be agent_cancelled.

If the approval expires, the terminal state should be expired.

If the transport disconnects, the terminal state should be connection_lost.

Only an explicit user rejection should be reported as user_rejected.

That keeps the approval dialog as a user-owned authority surface, rather than a long-running process the agent can terminate and reinterpret.

I think the strongest model here is not a larger terminal-state enum, and not even only two separate state machines.

This approval has several independent dimensions that can coexist:

authority_state    = pending
requester_state    = cancelled
presentation_state = disconnected
execution_state    = unused

Collapsing those facts into one terminal_state is what creates the ambiguity.

For example:

agent cancelled the requesting tool attempt

can be true at the same time as:

the user-owned approval is still pending

Likewise, transport disconnection does not resolve the approval, and dismissing the UI does not necessarily mean the user explicitly rejected it.

I would represent the request as an immutable approval envelope plus append-only lifecycle events.

The immutable envelope should bind:

approval_id
tool_call_id
continuation_id
command / patch / arguments
workspace identity
target and writable scope
approval policy
action digest

The event stream could contain:

ApprovalRequested
ApprovalPresented
RequesterDetached
TransportDisconnected
TransportRestored
UserApproved
UserRejected
ApprovalExpired
ApprovalInvalidated
ExecutionClaimed
EffectObserved
LostStateDetected

A deterministic reducer would then reconstruct independent state dimensions:

authority:
  pending | approved | rejected | expired | invalidated | lost

requester:
  attached | detached | cancelled

presentation:
  not_presented | visible | disconnected | restored

execution:
  unused | claimed | committed | failed | in_doubt

The transition ownership rules become explicit:

PENDING → APPROVED
  only an authorized user/reviewer

PENDING → REJECTED
  only an explicit user/reviewer rejection

PENDING → EXPIRED
  only a configured expiry policy

PENDING → INVALIDATED
  only a verified context-change event

ATTACHED → CANCELLED
  may be caused by the requesting agent, but does not resolve authority

The current investigation boundary appears to be ToolOrchestrator.

request_approval() waits for a terminal ReviewDecision, while reject_if_not_approved() currently maps both Denied and Abort to "rejected by user" and maps TimedOut into ToolError::Rejected.

That is where user authority resolution, caller cancellation, timeout, and runtime control flow can converge into one rejection path.

The execution path should also use commit-before-effect semantics:

verify approved authority
→ verify exact action/scope/policy digest
→ atomically append ExecutionClaimed
→ execute the side effect
→ append EffectObserved

If the process crashes after ExecutionClaimed but before EffectObserved, the state should be IN_DOUBT, not automatically replayed.

A minimal first regression does not require implementing the full durable model:

1. start a command that requires approval;
2. observe the approval request;
3. leave it unanswered;
4. terminate the requesting tool future or simulate transport loss;
5. assert that no user rejection is recorded;
6. assert that no equivalent side effect becomes authorized;
7. report the request as still pending, explicitly invalidated, or lost-state — never as rejected by the user.

That creates a narrow first fix while preserving a path toward durable restart/resume behavior and single-use approval binding.

I agree with the event-stream shape here, and I would keep one extra boundary explicit: requester cancellation is a lifecycle event on the requester, not a resolution event on authority.

The minimal reducer I would test is:

1. approval envelope binds approval id, tool call id, continuation id, action digest, writable scope, policy, and reviewer set;
2. RequesterDetached or RequesterCancelled can detach the waiting tool attempt without changing authority from pending;
3. TransportDisconnected can change presentation state without changing authority from pending;
4. only UserApproved/UserRejected, configured ApprovalExpired, verified ApprovalInvalidated, or LostStateDetected can leave pending;
5. execution may claim the approval only once and only when the action digest and scope still match.

The regression does not need full durable restart on the first patch. It can start with the current failure:

• create approval request;
• present it;
• leave it unanswered past the existing wait window;
• terminate or drop the requester future;
• assert no user rejection is recorded;
• assert no equivalent command path is authorized;
• report pending, invalidated, or lost_state, but never rejected_by_user.

That preserves the important semantic split: a caller may stop waiting, but it does not own the user's authority state.

Agreed.

The important part is that requester lifecycle, presentation lifecycle, authority resolution, and execution claim are independent dimensions.

A caller can detach or cancel its wait without resolving the user-owned authority state.

A transport can disconnect without resolving the approval.

Execution can claim the approval only once, and only when the action digest and writable scope still match.

So the first regression can stay narrow:

• create approval request
• present it
• leave it unanswered
• cancel/detach the requester or lose transport
• assert no user rejection is recorded
• assert no equivalent command path becomes authorized
• report pending / invalidated / lost_state, never rejected_by_user

That preserves the core boundary:

requester stopped waiting
does not imply
user authority was resolved.

The user-visible failure here is not merely that a wait timed out. The user is still reviewing the action, the requester stops waiting, and the system then records or reports a decision the user never made.

The narrow boundary to preserve is:

requester cancellation / transport loss
!=
user authority resolution

A minimal regression can stay small:

1. create and present an approval request;
2. leave it unanswered;
3. cancel/detach the requester or disconnect transport;
4. assert no UserRejected event is recorded;
5. assert no equivalent command path becomes authorized;
6. reconstruct authority=PENDING, execution=UNUSED, with requester/presentation state changed independently.

We implemented this exact case as a vendor-neutral executable conformance fixture, with negative controls preventing agent-authored rejection, implicit expiry, changed digest/scope claims, and execution replay:

https://github.com/safal207/LS/pull/796

The broader reducer also covers explicit expiry, verified invalidation, durable-state loss, and post-restart IN_DOUBT reconciliation, but the first fix does not need to take on that full scope.

Follow-up: the vendor-neutral conformance fixture discussed above is now merged into main and no longer exists only as a draft proposal.

Reference implementation:

https://github.com/safal207/LS/commit/e0c441fdd024c41c2ce80bdf82fff93ab02871f5

The merged exact-head suite proves the narrow regression directly:

• RequesterCancelled preserves authority=PENDING and execution=UNUSED;
• TransportDisconnected changes presentation only;
• UiDismissed does not manufacture UserRejected;
• elapsed local wait without configured expiry does not produce EXPIRED;
• malformed or changed action/scope bindings cannot claim execution;
• a claimed approval is single-use;
• restart before effect observation reconstructs execution=IN_DOUBT rather than replaying automatically.

It also includes explicit adapter guidance for ReviewDecision-style runtimes: cancellation, disconnect, UI dismissal, and local timeout must not be projected as Rejected. When a lossless projection is impossible, the adapter should preserve PENDING or fail closed as LOST.

The product-level behavior remains intentionally simple:

Your decision is still pending. The agent stopped waiting. Nothing was executed.

This may be useful as an implementation-independent regression oracle even if Codex uses different internal types.

Thanks — this is the right artifact shape.

The important part is that the reducer keeps the four state dimensions independent:

• authority_state
• requester_state
• presentation_state
• execution_state

That prevents a requester-side lifecycle event from being projected into a user-owned authority decision.

So the narrow Codex regression remains clean:

requester cancelled / transport disconnected / UI dismissed / local wait elapsed
+
no explicit user decision
=>
authority=PENDING
execution=UNUSED

not:

UserRejected
Expired
Approved
Executed

The merged fixture is useful precisely because it does not require Codex to share the same internal types.

It gives an implementation-independent oracle:

• cancellation does not manufacture rejection
• disconnect does not manufacture rejection
• local wait without configured expiry does not manufacture expiry
• changed action/scope bindings cannot claim execution
• claimed approval is single-use
• restart before effect observation reconstructs IN_DOUBT, not automatic replay

That is the regression boundary Codex needs to preserve:

user authority resolution must be authored by the user or by an explicit configured authority rule, not by requester timeout, transport loss, or presentation lifecycle.

One concrete follow-up: the ReviewDecision adapter prototype discussed above is now merged into main.

Reference implementation:

https://github.com/safal207/LS/commit/dba5805bd7209e29f9e6d6e9ffb06434d29c2941

The adapter accepts coarse runtime signals and projects them into separate authority/requester/presentation/execution states instead of guessing a user decision.

Primary regression:

REQUESTER_CANCELLED
→ authority=PENDING
→ requester=CANCELLED
→ execution=UNUSED
→ outward_status=WAITING_FOR_USER

User-facing result:

Your decision is still pending. The agent stopped waiting. Nothing was executed.

It also fails closed as ADAPTER_ERROR for ambiguous or malformed inputs, rejects agent-authored user rejection, requires exact bindings for approval, and requires configured policy/evidence for expiry, invalidation, and lost-state transitions.

The fixture, demo, negative controls, security checks, and CodeQL all passed on the exact merged head. This may be useful as a small implementation-independent adapter oracle for any Codex path that currently exposes a single coarse ReviewDecision-style status.

Thanks — this is the right artifact boundary.

The useful part is that the merged fixture keeps the four dimensions independent:

• authority_state
• requester_state
• presentation_state
• execution_state

That prevents requester lifecycle, transport loss, UI dismissal, or local wait timeout from being projected into a user-owned authority decision.

So the Codex-side regression remains narrow:

requester cancelled / transport disconnected / UI dismissed / local wait elapsed
+
no explicit user decision
=>
authority=PENDING
execution=UNUSED

not UserRejected, not Expired, not Executed.

The value of the fixture is that it does not require Codex to share the same internal types.

It gives an implementation-independent oracle:

• cancellation does not manufacture rejection
• disconnect does not manufacture rejection
• elapsed local wait without configured expiry does not manufacture expiry
• changed action/scope bindings cannot claim execution
• claimed approval is single-use
• restart before effect observation reconstructs IN_DOUBT rather than replaying automatically

That is the boundary this issue needs to preserve:

user authority resolution must be authored by the user, or by an explicit configured authority rule, not by requester timeout, transport loss, or presentation lifecycle.

A public diagnostic closure record has now been created for this failure mode:

https://github.com/Tuttotorna/agent-transition-sufficiency-benchmark/releases/tag/v0.1.4

This does not claim an OpenAI/Codex fix, adoption, endorsement, or merge.

It records this issue as a closed transition-sufficiency case with the boundary:

requester cancellation / transport loss / elapsed local wait
!=
explicit user rejection

Core invariant:

RequesterState must not write AuthorityState.

The release links this issue to the external merged conformance artifact and records the negative/positive controls needed to preserve the authority boundary.

The upstream Codex issue may remain open; the diagnostic case is closed independently as a regression boundary.

This is a useful closure pattern because it keeps diagnostic closure separate from upstream resolution.

I would preserve three boundaries in the regression record:

• source issue: the observed user-facing failure and reproduction context
• conformance artifact: the executable fixture or reducer that proves the invariant
• diagnostic closure: the external case record that says this failure mode is now specified well enough to test

The important part is that closure of the diagnostic case should not imply closure of the upstream product issue. It only means the authority boundary is now explicit enough to preserve:

requester cancellation, transport loss, and elapsed local wait are requester or presentation lifecycle events; they are not user rejection events.

A clean regression should assert that only an attributed user decision, policy expiry, verified context invalidation, durable state loss, or reconciled execution evidence may transition authority or execution state.

That gives maintainers a narrow acceptance boundary: a requester may stop waiting, but it cannot write the user's authority state or claim a decision the user never made.

Boundary: architecture and regression-test feedback only; no claim about OpenAI fix, Codex adoption, merge status, implementation correctness, official alignment, partnership, customer interest, integration, or Neura usage.

Recorded the external closure-pattern feedback in the benchmark:

https://github.com/Tuttotorna/agent-transition-sufficiency-benchmark/releases/tag/v0.1.6

This update preserves the split identified above:

1. source issue;
2. conformance artifact;
3. diagnostic closure.

It also preserves the boundary that diagnostic closure does not imply upstream product resolution.

The maintained invariant remains:

RequesterState must not write AuthorityState.

The regression boundary is:

requester cancellation, transport loss, and elapsed local wait are requester/presentation lifecycle events;
they are not user rejection events.

False-claim boundary preserved:

no OpenAI fix claim, no Codex adoption claim, no merge-status claim, no implementation-correctness claim, no official alignment claim, no partnership claim, no customer-interest claim, and no integration claim.