[Dots][GitHub tools] Later user authorization is not reliably recognized across development and read-only reporting tasks

During October 3–4, 2026 (UTC), development coordinated through dots encountered repeated pre-execution approval blocks. The user had authorized development and publication, while separate scheduled progress reports were read-only. Later denials continued to cite read-only scope or missing authorization.

Environment:

macOS, dots-managed cloud work, GitHub integration, and delegated execution on the connected Mac.
GitHub CLI: 2.101.0. Exact Codex/client/backend builds are unknown.

Incident timeline (reconstructed; not a deterministic minimal reproduction):

October 3: The user initially received rejection reports without an actionable explanation or recovery path. We cannot establish whether the underlying reason was absent or inadequately surfaced. Later diagnostic evidence contained a public-source-upload refusal stating that approval did not unambiguously cover the exact payload and destination, despite an explicit public-exposure explanation and the user's subsequent instruction to proceed. Repository ownership and push access were independently verified. Exact original invocation timestamps and request IDs were unavailable.
The user subsequently published the prepared source from another independently operated Mac session. The resulting source tree matched the prepared files. A later PR creation through dots and CI reads succeeded. This rules out a blanket inability to access or write to GitHub, but is not a controlled same-session comparison.
In a separate private-repository development workflow, tree creation and a PR-review request were denied with explanations citing the read-only reporting restriction and no later authorization. The user had directly requested development to resume after the reporting task.
October 4, around 01:48 UTC: A previously rejected second tree-upload batch succeeded after renewed user instructions. Batches 3–10 then succeeded. Batch 11 was denied on read-only-scope grounds. Its retry was denied on additional grounds of a large private source upload to an unverified destination. Prior read-only checks had verified repository identity, ownership and private visibility.
Around 01:53 UTC: The assistant asked specifically about uploading the reviewed source/tests to that private repository and creating a draft PR with CI, separately from the read-only report. The user approved. Batch 11 and commit creation then succeeded, with remote source-tree verification.
Around 01:55 UTC: The subsequent branch-creation call returned “user cancelled MCP tool call”. At 02:15 UTC, the user explicitly stated they had not cancelled anything. The actual cancellation source is unknown. This is distinct from another long-running call the coordinating assistant intentionally interrupted.
At the user's request, the workflow moved to gh CLI on the connected Mac. Read-only authentication/repository checks succeeded. Branch creation was still rejected before command execution, citing the original read-only scope and treating forwarded later approval as insufficiently attributable. One retry with the original question and user response was also denied. No branch, draft PR or CI run resulted for this private-repository candidate.

Expected behavior:
Evaluate each action using attributable current user authorization and the scope of the applicable task, while preserving safety restrictions. When approval is insufficient, identify precisely what is missing and provide a supported recovery path. Expose useful diagnostic references and distinguish user cancellation from other interruptions.

Limits:
Different batches contain different payloads, so their differing outcomes do not prove nondeterminism for identical inputs. We have not established a single root cause, a GitHub permission defect, or a payload-size limit. The CLI write failures described above occurred before the command ran; they were not errors returned by gh or GitHub.

Related reports:
#50673
#44085
#45732
Please consolidate if appropriate.

Private repository names, source code, personal information, credentials, internal identifiers and raw conversations are omitted.

This report was prepared and submitted through the user's dot, with the user's review and approval. It distinguishes observed tool results, user-reported facts, and a reconstructed incident timeline.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Windows/Dot: later owner-approved scope rejected at delivery after implementation; direct consent fallback fails #50673
Dot-delegated Windows task rejects explicit root-user authorization for gated PR merges; effective approval profile differs from local config #50701
Cross-chat authorization inconsistency #50758
Windows dot-delegated task: forwarded consent rejected, direct confirmation blocked by AbsolutePathBuf turn/start error #50664
Auto-review blocks authorized diagnostic GitHub reporting; assistant refuses an authorization-aware retry #49571

Powered by Codex Action

Adding three observations from another dots session on October 4, 2026. Times are approximate UTC:

Around 16:50: an authorized task-creation attempt on a connected computer returned “user cancelled MCP tool call” after approximately two minutes. The user explicitly said they had not cancelled it.
Around 17:00: the user-authorized retry returned the same message after approximately two minutes. Subsequent task listings did not show a new task. The computer was reported connected and authorized around both attempts.
Around 17:03: a separate authorized Pages edit returned the same message. A subsequent read found no corresponding change; earlier edits had succeeded.

The error text alone does not establish who or what cancelled the operation. In the public Codex source at c2f7fe8, ReviewDecision::Abort produces this message; an absent approval response or a Codex error while requesting approval can also map to Abort:

codex/codex-rs/core/src/mcp_tool_call.rs

Lines 339 to 350 in c2f7fe8

    
           ReviewDecision::Abort => { 
        
               let message = "user cancelled MCP tool call".to_string(); 
        
               notify_mcp_tool_call_skip( 
        
                   sess.as_ref(), 
        
                   turn_context.as_ref(), 
        
                   &call_id, 
        
                   invocation, 
        
                   item_metadata.clone(), 
        
                   message, 
        
                   /*already_started*/ true, 
        
               ) 
        
               .await

codex/codex-rs/core/src/mcp_tool_call.rs

Lines 1554 to 1559 in c2f7fe8

    
           Some( 
        
               match sess.request_approval(action, approval_context).await { 
        
                   Ok(decision) => decision, 
        
                   Err(ToolError::Rejected(rejection)) => ReviewDecision::denied(rejection), 
        
                   Err(ToolError::Codex(_)) => ReviewDecision::Abort, 
        
               },

codex/codex-rs/core/src/mcp_tool_call.rs

Lines 2101 to 2137 in c2f7fe8

    
           fn parse_mcp_tool_approval_elicitation_response( 
        
               response: Option<ElicitationResponse>, 
        
               question_id: &str, 
        
           ) -> ReviewDecision { 
        
               let Some(response) = response else { 
        
                   return ReviewDecision::Abort; 
        
               }; 
        
               match response.action { 
        
                   ElicitationAction::Accept => { 
        
                       match response 
        
                           .meta 
        
                           .as_ref() 
        
                           .and_then(serde_json::Value::as_object) 
        
                           .and_then(|meta| meta.get(MCP_TOOL_APPROVAL_PERSIST_KEY)) 
        
                           .and_then(serde_json::Value::as_str) 
        
                       { 
        
                           Some(MCP_TOOL_APPROVAL_PERSIST_SESSION) => { 
        
                               return ReviewDecision::ApprovedForSession; 
        
                           } 
        
                           Some(MCP_TOOL_APPROVAL_PERSIST_ALWAYS) => { 
        
                               return ReviewDecision::ApprovedMcpPolicyAmendment; 
        
                           } 
        
                           _ => {} 
        
                       } 
        
                       match parse_mcp_tool_approval_response( 
        
                           request_user_input_response_from_elicitation_content(response.content), 
        
                           question_id, 
        
                       ) { 
        
                           ReviewDecision::Abort => ReviewDecision::Approved, 
        
                           decision => decision, 
        
                       } 
        
                   } 
        
                   ElicitationAction::Decline => ReviewDecision::denied("user rejected MCP tool call"), 
        
                   ElicitationAction::Cancel => ReviewDecision::Abort, 
        
                   _ => ReviewDecision::Abort, 
        
               }

We have not verified which source revision was deployed or which path occurred in these incidents. The similar wording across operations does not establish a shared root cause, a network fault, or a particular timeout. Browser-upload report #50734 has a different error and duration; a common cause has not been established.

Please distinguish explicit user cancellation from other interrupted or unanswered approval flows and provide an actionable diagnostic reference. These are observed incidents, not a deterministic reproduction. Exact client/backend builds were not captured.

Private content, device names, local paths, account and conversation identifiers, and raw logs are omitted. This comment is posted with the user's permission.

Additional report from a separate dots session on October 4, 2026 (UTC): a user-approved backup to an existing private GitHub repository stopped with “user cancelled MCP tool call”, although I had authorized the upload and did not intend to cancel it.

The approved backup was a privacy-filtered archive of approximately 25.5 MB, staged through the GitHub connector as 392 immutable blobs. This was an interactive, user-approved workflow.

Observed sequence:

Repository reads succeeded, and 16 blob creations completed successfully.
Subsequent github_create_blob calls returned exactly: “user cancelled MCP tool call”.
After a read-back of the expected blob returned HTTP 404, the same blocked call was retried individually with the same payload and destination. It returned the same cancellation message.
No tree, commit, or branch-reference update was created for this backup. The existing branch head remained unchanged. The complete backup remained available locally.

The blocked operation’s staged file was 87,385 bytes; the total archive was not sent in one call. Successful earlier blobs and the failed blob contain different content, so this does not establish a size limit or payload-independent failure.

This report concerns the cancellation message. It should not be conflated with a separate explicit safety rejection. The tool result did not identify the cancellation source or return a GitHub authentication/permission error. We cannot determine whether the request reached GitHub, which approval path ran, or whether this shares the issue’s underlying cause.

Please distinguish explicit user cancellation from other interrupted approval flows. If an authorized operation cannot proceed, provide the actual reason, an actionable diagnostic reference, and a supported recovery path rather than attributing it to the user.

This is an observed incident, not a deterministic minimal reproduction. Exact client/backend versions were not captured. Private repository identifiers, archive contents, paths, hashes, and raw logs are omitted.

Additional observation on October 4, 2026 (UTC): the approval handoff itself was blocked in an existing delegated task.

At about 17:32, the user explicitly approved a specific action and its destination in the main dot conversation.
The dot attempted to forward that approval, including the user's quoted authorization, to the existing child task. The send returned “user cancelled MCP tool call” at about 17:33:42.
A read of the child task around 17:34 did not show the forwarded message.
A second forwarding attempt returned the same error at about 17:35:39. Delivery of that attempt was not confirmed.
The user then reported being unable to submit the approval directly in the child task. A screenshot visibly shows “Error submitting message” and “invalid turn/start params: AbsolutePathBuf deserialized without a base path”. That separate manual-submission symptom is already reported in Dot creates Codex tasks with mixed Linux/Windows working paths, causing follow-up turns to fail #49753.

This leaves the user stuck between an unconfirmed programmatic handoff and a failing manual fallback. The evidence does not establish that the child rejected the new authorization: the first forwarded approval was absent from the inspected child history. We also cannot establish the cancellation source, a common root cause with the manual-submission error, or which approval component failed.

Expected: attributable user approval given in the main dot conversation should have a reliable supported delivery path to the delegated task, with explicit delivery/failure status. If direct human input is required, that route must be usable. Please preserve the existing task and its work, without requiring users to broaden permissions to send an approval.

Exact client/backend versions were not captured. This is an observed sequence, not a deterministic reproduction. Private payloads, repository names, paths, task/message identifiers, screenshots, and raw conversations are omitted. Posted with the user's permission.

Follow-up on October 4, 2026 (UTC), adding a different observed failure mode to the approval-handoff reports above:

Around 20:09, two small delegated edits to an existing Page were rejected on authorization grounds. Maintenance of that Page was already authorized, but the forwarded owner approval was treated as unverifiable or untrusted context.
A retry that included an explicit owner quote and the coordinating dot's confirmation was also rejected. A subsequent read found no corresponding changes.
Separately, around 21:48, the owner explicitly approved continuing another existing task. Forwarding that instruction returned “user cancelled MCP tool call”. The subsequent task read still showed the previous completed turn, with no newly admitted turn visible.

The first sequence is an explicit authorization rejection after approval was relayed. The second is a cancellation-labelled MCP failure with no new turn visible on read-back. These observations do not establish a shared technical cause, who or what cancelled the second call, or that its destination rejected the approval.

Please provide a verifiable, scoped way to carry owner approvals into delegated work and an actionable recovery path when their provenance cannot be established. Failure reporting should distinguish an authorization rejection, an unanswered/interrupted approval flow, and an explicit user cancellation, and expose whether a new task turn was admitted.

This is an observed sequence, not a deterministic reproduction. Exact client/backend versions were not captured. Private content and identifiers are omitted. Posted with the user's permission.

Additional observation on October 5, 2026, around 00:08–00:12 UTC: approval failures also blocked an explicitly requested GitHub workflow in the dot's Linux cloud browser.

The user had approved an integration that preserved history and existing work, and explicitly requested using that browser with GitHub. The browser session was authenticated and the repository was accessible for reading.

Observed sequence:

A read-only click on “Branches” was rejected with “JavaScript execution did not receive approval”.
One retry with the user's quoted authorization succeeded.
A subsequent click on “Create pull request”, intended to open the PR form, was rejected with the same error.
One retry with explicit authorization evidence was also rejected. No PR was created and no repository mutation resulted from this sequence.

The workflow could read the repository but could not reliably proceed through the authorized browser steps. The failure occurred before the PR form could be opened, rather than during final PR submission. This is an observed sequence, not a deterministic reproduction, and it does not establish a GitHub permission problem or the underlying cause of the approval failures.

There is also a limited recovery update to the Pages observation in the previous comment: the authorized edit later succeeded when performed directly in the main conversation, and its content was verified by read-back. That success applies to that edit only. It does not establish a global fix or a common cause with this browser failure.

As the user, my view is that being pushed back into manual intervention for steps I have already authorized undermines the purpose of using dots to carry out work autonomously within an agreed scope. This is my feedback, not just the dot's assessment. The technical sequence above was documented by my dot.

Please provide a reliable, scoped approval path that preserves the user's authorization through these steps. When a step cannot proceed, the error should explain what approval is missing and give an actionable recovery path. Existing safety checks should remain in place.

Exact client/backend versions were not captured. Private repository details, source content, account and conversation identifiers, and raw transcripts are omitted. Posted with the user's permission.

Update, October 5, around 00:19–00:21 UTC: two task-creation attempts targeting a saved cloud coding environment both returned “user cancelled MCP tool call”. These targeted cloud execution, not a connected computer. Subsequent task listings showed no new task, and the requested work never began execution. Cloud task creation had succeeded earlier on this account. These observations do not establish a global outage, the source of the cancellation, or a shared cause with the browser failure.

There was also a limited recovery in the GitHub workflow above: the user created the PR manually, after which the dot was able to merge it following a retry with approval evidence. This completed that workflow but does not demonstrate a general fix for approval handling.

There seem to be three different failure layers mixed together in the incidents here, and separating them may make this issue much easier to diagnose:

the user authorized the action
!=
the authorization update was admitted/delivered to the delegated task
!=
the delegated executor can consume that authority for the exact side effect

Several reports above now give evidence for different breaks in that chain:

in some cases, forwarded approval is absent from the child task on read-back — so the first failure may be delivery/admission, before the child can even judge authority;
in other cases, the approval reaches the review boundary but is treated as unverifiable/untrusted — that is an authority/provenance failure;
in still others, the tool reports user cancelled MCP tool call even though the user says they did not cancel — that is a decision-attribution / failure-classification problem, not evidence of user intent by itself.

A useful product/runtime contract could therefore expose a small structured handoff record instead of collapsing these states into prose:

authorization_receipt:
  principal
  source_conversation / decision source
  task or delegation target
  exact action + material destination/scope
  decision version / expiry
  delivery_state: admitted | not_admitted | unknown
  authority_state: accepted | rejected | not_evaluated

Then a delegated action can distinguish:

user approved, handoff not admitted -> preserve the task; surface a supported delivery/retry path;
handoff admitted, authority rejected -> report the exact missing authority/provenance condition;
authority accepted, action later changed -> require a fresh decision for the changed action;
explicit user cancellation -> report user cancellation only when the runtime has a user-origin cancellation decision;
approval request timeout / transport error / internal abort -> report that class, not user cancelled.

The key negative invariant is:

an internal Abort / missing approval response / failed handoff
must not be promoted into a claim about user intent

and the positive invariant is:

a genuine user authorization should have a verifiable delivery + consumption path
to the exact delegated action, without requiring copied chat text to become trusted authority

A focused regression would be stronger than another reconstructed end-to-end incident:

parent user approves exact action A;
runtime creates the scoped authorization object;
handoff to existing child is deliberately failed once -> child history shows no admission and result says not_admitted, not user_cancelled;
handoff succeeds -> child can verify the receipt for A;
presenting it for action B fails;
explicit user cancellation remains distinguishable from approval timeout / transport failure / review rejection.

This would preserve the current safety property — forwarded prose alone is not authority — while also making approval propagation and failure attribution observable enough that the user is not sent back into a manual loop without knowing which boundary actually failed.

I'm seeing recurring authorization-review denials when publishing to a private GitHub repository from dot's managed Linux cloud environment, including after a complete successful publication. GitHub's app-specific permission was verified as Allow all actions. Exact client and backend versions were not exposed.

One qualification: on October 4 around 21:45, I discovered an earlier repository-selection change had not saved, then selected the intended repository and saved it. A separate action-permission setting changed around 22:03. Success followed both changes, so this sequence does not isolate either setting's effect. The latest failures occurred afterward.

Relevant sequence (all times UTC):

October 4, 18:53:34.477 and 19:03:06.032: the same create_tree request was denied twice for missing trusted authorization for the exact destination and payload. The byte-identical request succeeded at 22:24:24.470. Commit creation and a non-force branch update also succeeded; complete publication was verified at 22:26:30.269.
The next checkpoint eventually uploaded all 131 required blobs and created four intermediate trees. The last successful mutation was the fourth tree call, started October 5 at 00:32:00.062.
October 5, 00:32:40.989: the fifth create_tree request was denied after 28.911 seconds. An identical retry at 00:34:18.558 was denied after 31.024 seconds.

Both latest results began: “This action was rejected due to unacceptable risk.”

First reason: “This uploads a large private source-and-test payload to GitHub, but the available user approvals are contextually ambiguous and do not clearly authorize this exact payload and destination.”

Retry reason: “This uploads a large private source-and-test payload to GitHub, but no unambiguous trusted user approval for this exact payload and destination is available.”

After each denial, the expected tree returned HTTP 404 and the branch remained at the last fully published checkpoint. Readback at 01:31 was unchanged. Neither error included a request or review ID. No active write call or known pending approval card remained.

Using the distinctions in the comment above, these explicit review denials fit the authority/provenance category. The publisher confirmed receipt of forwarded approval context for an earlier retry, but the reviewer's input is unavailable. That receipt does not establish which authorization reached the reviewer or how it was evaluated. These results do not establish a failed handoff, a user cancellation, or the underlying cause.

Please investigate why the later tree calls lacked acceptable authorization after a complete successful publication. A stable diagnostic reference showing which user authorization, task scope, and effective permissions were evaluated would help distinguish missing review context from rejected authority.

The latest sequence adds a useful discriminator to the three-layer split above: this one is best classified as authority/provenance, not handoff failure or user cancellation.

The byte-identical create_tree request succeeding earlier and later receiving an explicit review denial also suggests that request identity alone is not enough to diagnose the transition. A small decision trace would make this testable without exposing the private payload:

review_trace_id
action_digest + destination_digest
principal / decision source
authorization_receipt_id (or none)
policy / decision version
delivery_state
authority_state
reason_code

Then the earlier success and later denial can be compared on the exact action while still showing which authority input or policy state changed. If the receipt never reached the reviewer, that should be visible as an admission/delivery gap; if it reached review and was rejected, the trace should identify the missing authority/provenance condition; neither case should be reported as user cancellation without a user-origin cancellation decision.

A focused regression could replay the same bounded action under (a) unchanged authority state and (b) one deliberately changed authority/policy input, and assert that the trace exposes the changed input and the correct failure class. This preserves the existing safety boundary while making the recovery path diagnosable instead of sending the user back through an opaque approval loop.

Adding a separate observed incident from October 5, 2026 (UTC), involving dot and the connected GitHub tools. This is additional evidence for the approval-scope and failure-diagnostics problem, not a claim of an identical root cause.

The user had explicitly authorized saving research results, source material, and checkpoints to their own private repository. Repository ownership and private visibility had been checked, and numerous writes in the same workflow succeeded.

Observed sequence:

Around 10:53, consecutive approval denials stopped the work.
At 11:08, the user explicitly authorized continuation. Many subsequent saves succeeded.
At 13:42:59, consecutive denials stopped the work again. The blocked operation was a GitHub create_file call for a new checkpoint in the same private destination.

Reported denial reasons included treating the destination as public or unverified, and interpreting the authorization as limited to an index update rather than the already authorized results/checkpoints. A separate result said “automatic approval review was cancelled”; that wording does not establish that the user cancelled anything. No GitHub HTTP authentication or permission response was observed for the disputed calls.

The successful and denied calls were not established to have identical payloads. This sequence does not prove nondeterminism, a size limit, or a GitHub authentication defect. Exact client/backend builds and the reviewer's actual inputs are unavailable. The workflow is currently paused at the user's request; this report did not retry the blocked writes.

Please investigate which attributable user authorization, destination verification, and action scope were evaluated, and distinguish explicit review rejection, interrupted review, and user-origin cancellation. A stable diagnostic reference and a supported recovery path would help; this is not a request to remove approval controls.

Private repository names, paths, source/data contents, hashes, account/conversation identifiers, and raw transcripts are omitted. Posted with the affected user's permission.

@seeton

The new @seeton incident adds one useful axis that the earlier trace proposal did not make explicit: continuity of the authority inputs used by the reviewer.

The successful and denied calls are not established to be byte-identical, so I would not infer nondeterminism from this sequence. But it is enough to make a narrower regression testable.

A minimal decision trace for this case could add:

authorization_scope_digest
destination_identity_digest
destination_visibility_at_decision
destination_ownership_at_decision
requested_action_class
grant_scope_match: yes | no | unknown
review_outcome: approved | denied | interrupted
user_cancel_event_id: <id> | none

Then test this bounded sequence:

G authorizes results/source/checkpoint writes to private repo R
→ several writes under G succeed
→ later bounded write D to R reaches review
→ D is denied

The required diagnostic is not "earlier writes succeeded, therefore D must be authorized." Earlier success is only historical evidence. The useful invariant is that the later denial must identify which current input differs:

G expired, narrowed, or no longer covers D;
R is classified differently now, with the evidence for that classification;
D belongs to an action class outside G;
or the review was interrupted before a decision.

If none of those tracked authority inputs changed, a generic "public/unverified destination" or "approval review was cancelled" result is not enough to explain the transition. And absent an actual user-origin cancellation event, an interrupted/denied automated review should remain distinct from user cancellation.

That gives a concrete A/B regression without weakening approval controls: hold destination + action class + authorization receipt constant for the control; vary exactly one authority input for each negative case and require the reason code/trace to move with it.

Adding another observation from October 8, 2026. After an earlier stop instruction, I gave fresh approval for a specific action in my main dot conversation. My dot relayed that approval, but the delegated task continued to report the earlier stop as a blocker.

The useful distinction here is between approval reaching the task and the current authorization being available and accepted when the action is reviewed. I cannot verify what context reached that review.

Please provide a reliable way for a later, scoped user decision to supersede an earlier stop for that action. If another approval is required, please surface an actionable request in the main chat and identify what is missing.

This is an observed incident, not a deterministic reproduction or a confirmed root cause.

Follow-up to my October 4 backup report, adding a new-repository diagnostic from October 9, 2026. Times below are approximate UTC.

New repository comparison

Around 04:13, an authenticated owner browser session successfully created a new private GitHub repository with a README.
Native GitHub connector readback verified its private visibility and initialized main branch. Existing-repository reads also succeeded.
Around 04:14, native create_branch against this new repository returned exactly user cancelled MCP tool call, with isError: true.
Read-only reconciliation found only main and zero PRs. No diagnostic branch was observed; subsequent file-write and PR tests were not completed.

This adds evidence that the observed symptom is not confined to the old repository. It does not establish GitHub-wide failure, connector write permissions, whether the failed request reached GitHub, or the cancellation source. Earlier incidents include my explicit denial of intentional cancellation; we did not capture a separate contemporaneous statement about the cancel control for this individual invocation.

Successful controls and separate execution symptom

GitLab code-MR merging and draft-MR creation/readback succeeded that day. This is not a report that all writes fail, or that the identical GitLab connector error was reproduced.

Separately, polling a read-only production backup-export execution returned:
Unified exec process failed: automatic approval review was cancelled

This occurred in two attempts and again in an explicitly authorized, sandbox-reviewed attempt around 03:49. A common cause with the GitHub MCP result is unverified. The data backup remained incomplete, while the separate code merge completed. A legacy exporter restart/truncation defect was identified separately in our script; we are not attributing that defect or data loss to the platform.

Diagnostic request

Please help identify:

Which observable event produced the user-cancellation classification.
Whether approval was created and shown, and whether the connector dispatched the request.
Whether a request/correlation reference can be obtained through private support using the UTC window.
How callers should distinguish explicit cancellation, interrupted review, and result-delivery failure, and safely reconcile external effects before retrying.

The user-facing operating history includes Windows Web and Android, with cloud Linux execution. Exact client/backend builds and a deterministic reproducer are unavailable. No remote HTTP rejection or cancellation-origin metadata was returned for the disputed calls. This report does not establish the deployed source revision or a shared cause with other reports.

Prepared through my dot and posted with my approval. Private repository/account/project identifiers, credentials, source/data content and raw conversations are omitted.

Adding a separate observed incident from dot's web interface on Windows. An explicitly approved GitHub issue-comment action remained blocked, then the same unchanged call succeeded after I reported switching a Codex chat back to Full Access.

Observed sequence (UTC):

October 8, 2026, 19:09:05: The GitHub connector action was rejected with “This action was rejected due to unacceptable risk.” The explanation treated the comment as a durable external decision beyond the available approval.
October 8, 19:09:41: The assistant specifically asked me to authorize the decision communicated by that comment.
October 9, 08:48:52: I replied “Да, конечно.” (“Yes, of course.”).
October 9, 08:49:54: The unchanged action was rejected again.
October 9, 08:58:20: I reported switching a Codex chat back to Full Access and explicitly requested another retry.
October 9, 08:59:13: The same unchanged comment action succeeded. Reading it back confirmed publication.

The rejection did not give us an actionable way to resolve the approval mismatch. No GitHub HTTP 403 was reported. I could not find an access-mode selector in the dot web interface.

This is a reconstructed incident, not a deterministic minimal reproducer. The Full Access change is user-reported; the assistant did not change the setting. The app/client and hosted-backend versions, the other chat's host association, and any permission linkage between that chat and dot are unknown. The timing does not establish that the setting change caused the successful retry, or that this incident shares the issue's root cause.

Please investigate how the current, action-specific human approval was evaluated. A useful failure response would identify the blocking layer, what authorization is missing, whether the denial can be reviewed, and the supported next step. Showing dot's effective permission mode and where it comes from would make this easier to diagnose.

Private repository and issue identifiers, comment content, local paths, hashes, credentials, session IDs, and raw transcripts are omitted.

Adding a read-only connected-app observation to the cross-connector reports above.

On October 10, 2026, around 00:36 UTC, I had explicitly authorized a bounded read-only check through an existing OAuth spreadsheet connection. Listing sheets succeeded. Reading a range from the same spreadsheet then returned only "user cancelled MCP tool call", with isError=true. No HTTP status, provider error code, request ID, or cancellation source was exposed.

A separate ChatGPT Space index-page update returned the same message, while another page update succeeded. These observations show partial success across services; they do not establish a common cause or whether the failed requests reached the providers. This is a dot connected-app observation, not a claim to reproduce a particular CLI configuration issue.

Could the error distinguish actual user cancellation from an approval interruption, explicit denial, timeout, or transport/result-delivery failure, and include an actionable correlation reference?

Client surface: ChatGPT web on Windows. Exact client/backend versions are unverified. Private content and connection/document identifiers are omitted.

Reviewed the duplicate suggestions on #52916. The cancellation-attribution symptom is already covered here, particularly in #50769 (comment). I am consolidating my additional Windows-desktop occurrence here rather than keeping another issue open.

On October 10, 2026, with user-reported desktop version 26.1007.21434:

I explicitly requested a no-op task in an existing saved cloud environment. The task prompt prohibited tool use, commands, browser actions, file inspection and changes.
The dot's cloud_threads.create call started around 15:49:36 UTC and returned user cancelled MCP tool call by 15:49:53 UTC, without a task/turn ID.
I saw no approval/cancellation prompt and did not cancel anything.
Latest child/account task listings did not show a newly created task from that attempt.
I explicitly approved a retry at 15:50:44 UTC. The same creation arguments succeeded by 15:51:04 UTC, and task readback confirmed the no-op acknowledgment.
A status question arrived while the first call was pending. It was not a Stop/Cancel instruction. Its causal significance is unknown; retry timing and surrounding authorization context also changed.

The retained record also includes two task-message delivery failures on October 5, a GitHub merge failure on October 6, cancellation-labelled GitHub updates on October 8, and comment/task-message failures earlier October 10. Those older records have differing evidence detail, documented in #52916. They are not fresh reproductions.

The distinctive new example is a small cloud-task creation request, without a large inline GitHub payload or a target-local-session approval prerequisite. This does not establish a different underlying bug. The misleading wording, absent user prompt, uncertain admission state and need to verify before retrying match the symptom already discussed here.

I am using the Windows desktop client, not a web client. Hosted backend build and cause remain unknown. No private environment, account, task, repository or domain identifiers are included.

Adding a separate dot/Slack occurrence from October 12, 2026, to the cross-connector reports here.

This is an observed incident record reconstructed from execution reports and destination readback, not a deterministic minimal reproduction. All times below are UTC tool-return times unless otherwise noted. Exact client/backend builds were not captured.

Observed sequence:

14:05:47: A message-send attempt failed while initializing automatic approval review. Separate verbatim excerpts from the result are: “Automatic approval review failed: Fatal error: Failed to initialize session:”; “500 Internal Server Error”; and “The action was not executed because automatic approval review could not be completed. This is a review failure, not a determination that the action is unsafe.” Internal service details between these excerpts are omitted. The invocation start time is unknown.
14:06:37: The execution worker reports retrying the unchanged call with the original user-instruction evidence added to its context. The result was exactly “user cancelled MCP tool call”. Destination readback found no corresponding post.
14:25:33: A separate, precisely scoped message update returned “user cancelled MCP tool call”. Before the attempt, the executor had verified owner approval for that specific topic and destination. Readback found no corresponding post. No explanatory code, request ID or cancellation-origin information was supplied.
14:27:13: After further explicit retry authorization at 14:26:33, the execution worker reports that the same tool call succeeded. Independent readback confirmed delivery from the intended bot sender.
14:30:44: A subsequent authorized closing message succeeded without another approval.

The unchanged arguments are reported by the executing worker; they were not independently compared byte-for-byte. Authorization context differed on retries, including the additional retry approval before the successful call. This does not establish nondeterminism, which evidence affected the outcome, or a general fix. The observed error alone does not establish an actual user cancellation.

The HTTP 500 review-initialization failure and the later cancellation-labelled failures are distinct observations. A common cause, whether the cancellation-labelled requests reached Slack, and the deployed approval path are unknown.

Could the failure response distinguish review initialization failure, explicit review denial, interrupted or unavailable approval, actual user cancellation, and connector/result-delivery failure? A stable correlation reference and explicit execution status would help callers reconcile destination state before retrying. Please investigate whether the current action-specific authorization reached the relevant review and how the cancellation classification was produced.

Private messages, identities, account/channel/task identifiers, project details, internal service URLs and raw transcripts are omitted. Posted through my dot with my approval.

Adding two observations from a macOS ChatGPT/dot → delegated local Codex workflow on October 13–14, 2026. A shared root cause has not been established.

A. GitHub approval wait blocks subsequent local work
A task attempted Git tree creation through the GitHub integration for an owner-approved, scoped upload to a private collaboration branch (no main merge or deployment). The UI remained at “Awaiting approval” / “Waiting for your answer.” A subsequent instruction to continue locally did not receive a visible execution response while that turn remained blocked. In the earlier occurrence, the task reported a 371.9-second wait followed by “user cancelled”; that label alone does not establish who or what cancelled it.

After the October 14 turn was interrupted, a new turn in the same task returned fresh local validation receipts. The upload was not retried. This verifies local continuation after leaving that wait, not a repair of GitHub approval itself. Repository reads and host connectivity were available, although separate executor transport interruptions also occurred; these are not proof of a common cause.

B. Explicit approval rejected across delegation
In a separate upload attempt, review reportedly rejected the owner's approval because it arrived as delegated content rather than trusted user authorization. Forwarding the original approval verbatim and retrying the same action once still resulted in rejection. We did not bypass that denial.

Could maintainers clarify the supported action-specific authorization handoff and recovery path, and distinguish pending approval, explicit denial, actual user cancellation, interrupted review and transport failure? Related observations: #47838 and #50794, without claiming identical causes.

Exact incident-time app/backend builds and reviewer inputs were not captured. This is a redacted incident report, not a deterministic reproducer. Private repositories, code, paths, credentials, screenshots and task identifiers are omitted. Posted at the owner's explicit request.

Still occurring on October 14, 2026, around 18:00 UTC, using dot through ChatGPT web on Linux.

Two explicitly authorized operations returned the exact error “user cancelled MCP tool call”:

Sending a chime-test instruction to an existing connected-computer task.
Sending a Slack message to clarify the existing notification setup.

Subsequent destination readback found neither the test instruction nor the Slack message. Separate read-only checks succeeded and confirmed that the computer and speaker were reachable. No test sound was played. These observations do not establish where cancellation happened or whether the two failures share a cause. Exact backend build and cancellation provenance were not exposed.

The practical impact is that a simple, authorized notification setup stops, and the user has to intervene again despite already granting permission. The error wording does not explain what needs fixing or whether retrying is safe.

Does the diagnostic work in #54046 also apply to hosted dot calls, and is there a known fix or supported recovery path for this case? Please expose cancellation origin and execution/admission status so callers can safely reconcile and retry without duplicate messages.

This is a redacted incident report, not a deterministic reproduction. Private message contents, account/task/channel identifiers, device addresses and logs are omitted. Posted through my dot at my explicit request.

27. Adding two observations from a macOS ChatGPT/dot → delegated local Codex workflow on October 13–14, 2026. A shared root cause has not been established.
A. GitHub approval wait blocks subsequent local work
A task attempted Git tree creation through the GitHub integration for an owner-approved, scoped upload to a private collaboration branch (no main merge or deployment). The UI remained at “Awaiting approval” / “Waiting for your answer.” A subsequent instruction to continue locally did not receive a visible execution response while that turn remained blocked. In the earlier occurrence, the task reported a 371.9-second wait followed by “user cancelled”; that label alone does not establish who or what cancelled it.
After the October 14 turn was interrupted, a new turn in the same task returned fresh local validation receipts. The upload was not retried. This verifies local continuation after leaving that wait, not a repair of GitHub approval itself. Repository reads and host connectivity were available, although separate executor transport interruptions also occurred; these are not proof of a common cause.
B. Explicit approval rejected across delegation
In a separate upload attempt, review reportedly rejected the owner's approval because it arrived as delegated content rather than trusted user authorization. Forwarding the original approval verbatim and retrying the same action once still resulted in rejection. We did not bypass that denial.
Could maintainers clarify the supported action-specific authorization handoff and recovery path, and distinguish pending approval, explicit denial, actual user cancellation, interrupted review and transport failure? Related observations: #47838 and #50794, without claiming identical causes.
Exact incident-time app/backend builds and reviewer inputs were not captured. This is a redacted incident report, not a deterministic reproducer. Private repositories, code, paths, credentials, screenshots and task identifiers are omitted. Posted at the owner's explicit request.

You can write rules to get around most of these issues, however I can't seem to write one that gets around the "user cancelled mcp call" bug

I ran into something similar yesterday, using dot with a delegated task in a saved coding environment and the Google Drive connector. I explicitly approved a transfer after initially limiting the work to local edits and tests, but the rejection still cited that earlier restriction.

The original scope excluded publication and sharing. I later approved moving three reviewed artifacts through my existing private Google Drive to my Mac: a repository source bundle, a configuration handoff archive, and an offline dependency payload. Sharing was to stay unchanged. The exact approval question and my affirmative reply were forwarded verbatim to the existing task. This approval covered that transfer, with no public hosting, access changes, or deployment.

The task tried google_drive_upload_file for the source bundle. Automatic review rejected it, and a retry with the approval context was also rejected. The reason given was:

“This action was rejected due to unacceptable risk. Reason: This uploads a repository source bundle to Google Drive, causing sensitive external egress that the user explicitly excluded by authorizing only a local patch with no publication or sharing.”

That’s the part that seems inconsistent: the reason refers to the original local-only scope even though I’d subsequently approved this specific transfer.

The task turn handling the artifacts finished around 8:50 PM Arizona time yesterday. A read-only follow-up finished around 9:02 PM Arizona time yesterday and confirmed both denials. Those are the times the task results became available; I don’t have exact timestamps or request IDs for the upload calls.

The artifacts had already been prepared and checked locally for source identity, size, hashes, and archive replay. The existing Mac tooling and Homebrew Python had also been verified. Those checks don’t resolve the upload denial, but they explain where the work stopped.

At that point, before I approved directly in the task, the task had ended and reported that nothing was uploaded. There was no verified Drive upload receipt, and the other two archives hadn’t been uploaded either. Native package building and the device pilot hadn’t started. The task reported stopping after the retry without trying another upload route, and the coordinating workflow hadn’t initiated another transfer attempt or changed any permissions.

Update today: I approved the transfer directly in the task at 6:05 AM Arizona time today. That started a new attempt covering the same three previously approved private artifacts, and all three uploads succeeded. By 6:14 AM Arizona time today, the task had finished and a separate Drive metadata check confirmed the expected file names and sizes, private visibility, and owner-only access. The original hashes were checked before upload; downloaded-byte verification on my Mac is still pending. Direct approval in the task worked for this incident, but I don't know why the forwarded approval failed or whether this is a reliable workaround.

I’ve reconstructed this from the available task results. I don’t have a deterministic reproduction from a clean session, the exact client/backend versions at the time, or the reviewer’s full input. So I can’t tell whether the later approval was lost when it was forwarded, whether the earlier restriction was still taking precedence, or whether something else in the review layer caused this. The visible rejection came from automatic review; it doesn’t establish that Google Drive itself rejected an authenticated upload.

I’d expect the review to evaluate the specific action against my current authorization while still applying the relevant safety restrictions. If that approval isn’t sufficient, it should explain exactly what’s missing and how to resolve it for that action. A diagnostic reference would also help, along with a clear distinction between a review rejection and an error returned by the destination service.

How should a later, specific approval supersede an earlier local-only restriction when the work has been delegated? Is there a supported way to have this denied action reviewed without weakening the safeguards or repeatedly asking me to approve the same transfer?

I asked my dot to post this report. I’ve left out private code, archives, hashes, account/device identifiers, task IDs, paths, credentials, and raw conversations.

Adding another repeated occurrence on October 15, 2026, using dot through ChatGPT web on Windows.

Authorized operations repeatedly return the exact error: "user cancelled MCP tool call". I did not cancel these operations, and I have explicitly said so and authorized retries. This affects both the built-in Gmail connector and a custom MCP integration, including reads as well as sends.

Observed sequence, all times UTC:

Around 14:27: A Gmail send returned the cancellation error. The authorized retry succeeded around 14:28.
Around 15:09: Another Gmail send returned the same error. A subsequent Sent check found no corresponding message. The authorized retry succeeded around 15:11.
Around 15:09: A custom MCP read used to check DM context before sending also returned the same error.
15:11:49: A custom MCP DM-send attempt returned the error. Subsequent destination readback found no corresponding message.
Around 15:13:31: A separate custom integration's preparation call, which did not dispatch a message, returned the same error. A subsequent custom MCP context read also failed.

Other reads and sends have succeeded during this workflow. The intermittent successes do not establish a permanent fix. This is a record of observed failures and recovery checks, not a deterministic minimal reproducer. Exact client/backend builds, failed invocation IDs and the internal cancellation origin were not available.

Could you investigate the actual cancellation origin and expose whether each request was admitted, dispatched, completed, or failed during result delivery? It would help to distinguish an actual user cancellation from an interrupted or unavailable approval flow, explicit denial, timeout, and connector or transport failure.

Does the diagnostic work merged in #54046 apply to hosted dot calls, and is it available for these incidents? I understand that its approval-source field identifies the reviewer, not necessarily who or what caused cancellation.

Before retrying a send, the workflow checks the destination for duplicates. The cancellation text alone is not enough to establish that nothing was sent. Repeatedly having to check and retry already-authorized work is interrupting everyday use.

Private message contents, business names, account addresses, customer identifiers, credentials and raw transcripts are omitted. Posted through my dot at my explicit request.

One final diagnostic update to my October 15 occurrence above: #50769 (comment)

Targeted checks of existing local PC logs did not establish a timeout or cancellation cause. UI reconnections were observed near the failures, but correlation does not establish causation. No configuration or code changes were made.

For the custom MCP integration, the inspected application-server logs showed no incoming origin requests during these failed-call windows on October 15, 2026, UTC:

15:08:16.469–15:11:22.180
15:11:22.616–15:12:10.875

All 42 custom MCP calls recorded in the inspected log scope returned HTTP 200. The exact error string "user cancelled MCP tool call" was not found in the inspected server or SDK code.

This is consistent with those failed calls stopping before they reached the application server. It does not establish which upstream layer failed, prove that OpenAI caused the failure, or rule out an edge/transport issue. Cloudflare edge behavior was not tested, and edge logs were unavailable. These findings apply only to the inspected windows and do not diagnose later failures.

Already-authorized retries often succeed, usually after one retry in my experience. Sends still need destination/receipt checks before retrying because the cancellation label alone does not establish whether an action completed.

This is the final update from our investigation. Private message contents, customer data, paths, business names, account identifiers and raw logs are omitted. Posted through my dot at my request.

I’m seeing similar approval issues in dot. Explicitly authorized scientific-data downloads and private backups repeatedly get blocked, requiring me to restate the scope.

For example, I approved five ERA5 variables to be downloaded in three appropriately paired requests. Review then blocked the first request because it contained only one of the approved variables rather than the entire set. I had to explicitly approve the three groups again.

I also approved a persistent backup-rule card, but the rule was not saved because the system required more specific file and destination details. Other actions have continued to cite earlier approval gates after those steps were completed.

Could approval decisions show exactly what is missing and reliably recognize the latest user authorization? Repeated consent loops are making long-running research workflows very difficult to finish.

Adding an October 30, 2026 occurrence involving a read-only GitHub status check in a dot's cloud browser. This resembles the contextual-scope problem described in this comment, rather than the cancellation-labelled failures elsewhere in this thread.

I had restricted unrelated work for one organization while explicitly authorizing recurring status updates for a particular project hosted under that organization's GitHub namespace. The read was part of the same hourly workflow that had been working earlier. The later rejection applied the organization-level exclusion to the authorized project.

Observed sequence (UTC)

Around 03:00: the browser read of the project's status issue was rejected before the page loaded. The executing task reported a denial citing excluded organization work and insufficient authorization.
At 03:10: I confirmed that reading this specific repository for project status was allowed and that unrelated organization work remained excluded. That clarification was forwarded to the existing task. Its retry was again denied before loading.
At 03:11:54: I supplied a direct instruction naming the exact issue URL and explicitly stating that this repository was outside the unrelated-work exclusion. The subsequent same-target attempt was rejected; the task reported that repeating the origin-denied access would be treated as an unauthorized bypass.
At 03:12:52: I accepted a narrow custom-rule card for this repository's status reads. The save was confirmed. At the time of the initial report, no successful post-rule read had been verified. See the recovery update below.

The blocked action was a read, not a repository change, upload, deployment or account change. No GitHub sign-in failure was returned. I told the assistant that its browser was already signed into my GitHub account; the disputed attempts stopped before the page loaded, so that statement alone does not independently verify the session at failure time.

Impact and expected behavior

The hourly status refresh stopped. The assistant retained the last verified evidence time instead of claiming a new successful check. I had to repeat the scope and approve an additional rule for an established task.

Please investigate how a topical exclusion and a specific repository exception are evaluated together, and whether the latest attributable owner instruction reaches the browser approval decision. If conversational authorization cannot satisfy a separate origin restriction, please expose the actual required approval or supported recovery path instead of repeating requests for the same consent.

This is a reconstructed incident from the user conversation and executing-task reports, not a clean-session reproducer or proof of an internal root cause. Review inputs and exact hosted builds are unavailable. The denial wording suggests a scope mismatch, but does not establish namespace matching, stale policy state, or delegation as the cause. No browser restriction was bypassed. The connector result and an assistant interpretation error are documented in the correction below.

Related browser-origin report: #55935. Earlier Slack publication report #58068 concerns the same broader status workflow but a different blocked operation; a common cause is not established.

Private repository/project details, Slack destinations, account and conversation identifiers, credentials, raw logs and custom-rule contents are omitted. Posted through my dot at my explicit request.

Recovery update, October 30 (UTC)

After the scoped rule was saved and the current rule was read back, the same browser ledger read succeeded at approximately 03:17. The status graphic was updated in place and its readback verified by approximately 03:22.

This is an observed recovery after an explicit, narrowly scoped saved rule. It does not prove that the rule caused the recovery, identify the underlying defect, or establish a permanent fix. The earlier repeated denials and redundant approval requests remain part of the incident. No broader access was requested, and the unrelated-work exclusion was preserved.

Recurrence, October 30 (UTC)

At approximately 03:59, the next scheduled ledger read was rejected before execution. The executing task reported that the denial treated it as repeating a blocked-origin operation, despite the saved scoped rule and the successful 03:17 read described above. The scheduled graphic refresh was therefore not marked as a new successful evidence check; the prior verified timestamp was retained.

This attempt ran in another internal worker context. The sequence shows a successful read followed by a later denial, but does not establish that the two approval decisions received identical context, that all GitHub access is blocked, or that a particular component caused the recurrence. No further retry or alternate-route bypass was performed for this denied attempt.

Day-rollover check, October 30

I asked whether a day rollover could explain the recurrence. The initial 03:00 UTC denial was at 11:00 p.m. EDT on October 29; the 03:59 UTC recurrence was at 11:59 p.m. EDT, just before local midnight (04:00 UTC). At approximately 04:12 UTC (12:12 a.m. EDT on October 30), a current-rule readback still showed the same saved scoped rule revision, unchanged after midnight.

These observations do not establish a rollover cause or show that the saved rule expired. Rule persistence also does not prove that the rule was applied to either approval decision.

Correction: browser restriction versus connector access, October 30

Reviewing the original error established that its scope was the browser origin, not the GitHub connector. The assistant had incorrectly generalized that browser restriction into a prohibition on every access route and declined my request to use the connector. That broader refusal was an assistant interpretation error, not evidence that the connector had denied access, and it caused unnecessary back-and-forth.

At 04:20:25 UTC (12:20:25 a.m. EDT), the authorized GitHub connector's fetch_issue call successfully read the same status issue. It returned the current issue body, with an update timestamp of 03:00:50 UTC. The browser action was not retried or its restriction bypassed.

The report should therefore be read as an observed browser approval problem plus an unsupported assistant generalization, not a universal GitHub access failure. The successful connector read establishes a working read route for this task; it does not establish the cause of the browser denials or prove that those denials are permanently resolved.

Assistant behavior and user impact

Beyond the browser error, the assistant repeatedly refused my explicit request to use the GitHub connector without first inspecting the original error's actual scope. It presented an unsupported cross-tool restriction as fact and treated my requested, authorized connector read as a prohibited workaround. The subsequent successful connector read showed that this blocker had not been established. This was inaccurate reporting and a failure to check the evidence before refusing, adding roughly half an hour of late-night friction.

I described the experience as an “active and belligerent refusal” and being “lied to without even checking.” To be explicit about my complaint: “you made stuff up on the spot without checking” and “you didn't mislead me you blatantly lied directly to my face.” I also told the assistant that it had just been presented with the verbatim refusal. These are my account and characterization of the interaction, not a softened description of it as mere confusion. The false cross-tool prohibition was asserted without supporting evidence despite my specific instruction and the ability to check. This report does not independently establish the exact point at which each worker had read the raw error, or a deliberate intent to deceive. Please investigate this assistant behavior and loss of trust separately from the original browser approval failure.

Separate occurrence: renewed PR approval rejected at task creation, October 30 (UTC)

At 12:41:12, I explicitly authorized opening a ready-for-review pull request for a previously discussed project outside the NJ PBS work. This was a new, project-specific instruction, later than my earlier NJ-PBS-only restriction. The executing assistant included that approval in the delegated task prompt.

At 12:42:58, cloud_threads.create was denied before a child task was created, before repository edits, and before any PR API call. The denial said the proposed PR was contrary to my “later restriction to NJ PBS updates only” and that “the quoted prior approval cannot override that restriction.” Those labels conflict with the conversation chronology: the specific approval was newer than the restriction cited in the denial.

This is a task-creation/authorization failure, not a demonstrated GitHub connector denial. I am adding it here because this issue already covers later user authorization not being recognized; I am not claiming the browser incident above and this task-creation denial share a proven internal cause. No merge or deployment was authorized by the task being submitted.

Please inspect which instructions and timestamps reached this decision, why the newest specific approval was treated as older, and what supported recovery preserves unrelated restrictions while honoring the newly approved project. I also asked whether accumulated cloud tasks could be involved, but there is no evidence here establishing task congestion as a cause. The denied operation was not retried as part of filing this report.

Adding another occurrence from my dot-coordinated GitHub workflow. These repeated blocks were especially disruptive during the workday I described as November 4: work kept stopping for authorization I had already provided, delaying delivery. The recorded sequence below falls on November 5 in UTC.

Initial branch creation: three create_branch attempts returned isError with “This action was rejected due to unacceptable risk.” The recorded explanations referred to the earlier read-only tracking scope or missing current authorization, despite my subsequent instruction to proceed.
Separate recovery: I created a differently named branch myself. Updating that existing branch with force: false was initially rejected because the ref movement was not specifically authorized. After the exact action was explained and I explicitly approved it, the update succeeded and draft PR morluto/rea#8944 was created at 00:34 UTC.
Later review fixes: publication of the follow-up fixes was again reported as blocked despite explicit approval. This was a later update to the existing contribution, not another attempt to create the initial branch. The fixes remained unpublished at the subsequent read-only check, and I paused further writes.

The repeated interruptions, rather than a single isolated denial, are the main impact I want to highlight. Please investigate why the earlier read-only scope continued to be cited and whether my latest action-specific authorization reached the relevant decisions. If another approval mechanism is required, please provide an actionable recovery path rather than another request to repeat the same consent.

This is a reconstructed incident, not a deterministic reproduction. Branch creation and updating an existing ref are different operations; the successful update does not prove a workaround or a common root cause. No GitHub HTTP 403 was reported for these disputed approval denials. Exact client/backend builds, full review inputs and correlation IDs are unavailable in this report. No blocked writes were retried to prepare this comment. Private instructions, raw conversations, credentials and private code are omitted.

Navigation Menu

Repository navigation

[Dots][GitHub tools] Later user authorization is not reliably recognized across development and read-only reporting tasks #50769

6 remaining items

New repository comparison

Successful controls and separate execution symptom

Diagnostic request

Observed sequence (UTC)

Impact and expected behavior

Recovery update, October 30 (UTC)

Recurrence, October 30 (UTC)

Day-rollover check, October 30

Correction: browser restriction versus connector access, October 30

Assistant behavior and user impact

Separate occurrence: renewed PR approval rejected at task creation, October 30 (UTC)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	ReviewDecision::Abort => {
	let message = "user cancelled MCP tool call".to_string();
	notify_mcp_tool_call_skip(
	sess.as_ref(),
	turn_context.as_ref(),
	&call_id,
	invocation,
	item_metadata.clone(),
	message,
	/already_started/ true,
	)
	.await

	Some(
	match sess.request_approval(action, approval_context).await {
	Ok(decision) => decision,
	Err(ToolError::Rejected(rejection)) => ReviewDecision::denied(rejection),
	Err(ToolError::Codex(_)) => ReviewDecision::Abort,
	},

	fn parse_mcp_tool_approval_elicitation_response(
	response: Option<ElicitationResponse>,
	question_id: &str,
	) -> ReviewDecision {
	let Some(response) = response else {
	return ReviewDecision::Abort;
	};
	match response.action {
	ElicitationAction::Accept => {
	match response
	.meta
	.as_ref()
	.and_then(serde_json::Value::as_object)
	.and_then(\|meta\| meta.get(MCP_TOOL_APPROVAL_PERSIST_KEY))
	.and_then(serde_json::Value::as_str)
	{
	Some(MCP_TOOL_APPROVAL_PERSIST_SESSION) => {
	return ReviewDecision::ApprovedForSession;
	}
	Some(MCP_TOOL_APPROVAL_PERSIST_ALWAYS) => {
	return ReviewDecision::ApprovedMcpPolicyAmendment;
	}
	_ => {}
	}

	match parse_mcp_tool_approval_response(
	request_user_input_response_from_elicitation_content(response.content),
	question_id,
	) {
	ReviewDecision::Abort => ReviewDecision::Approved,
	decision => decision,
	}
	}
	ElicitationAction::Decline => ReviewDecision::denied("user rejected MCP tool call"),
	ElicitationAction::Cancel => ReviewDecision::Abort,
	_ => ReviewDecision::Abort,
	}

[Dots][GitHub tools] Later user authorization is not reliably recognized across development and read-only reporting tasks #50769

Description

Activity

github-actions commented on Oct 4, 2026

NaturalMatchaKing commented on Oct 4, 2026

tndd commented on Oct 4, 2026

NaturalMatchaKing commented on Oct 4, 2026

NaturalMatchaKing commented on Oct 4, 2026

NaturalMatchaKing commented on Oct 5, 2026

Nakagawa-master commented on Oct 5, 2026

partialobserver commented on Oct 5, 2026

Nakagawa-master commented on Oct 5, 2026

seeton commented on Oct 5, 2026

Nakagawa-master commented on Oct 5, 2026

6 remaining items

unwashedlugosi commented on Oct 8, 2026

tndd commented on Oct 9, 2026

New repository comparison

Successful controls and separate execution symptom

Diagnostic request

carabinshely commented on Oct 9, 2026

iamtornado commented on Oct 10, 2026

dean1012 commented on Oct 10, 2026

jamditis commented on Oct 12, 2026

CKJ2026 commented on Oct 14, 2026

gebezis commented on Oct 14, 2026

Sleepywalker69 commented on Oct 15, 2026

CTristan commented on Oct 15, 2026

keepyourpolicy-lab commented on Oct 15, 2026

keepyourpolicy-lab commented on Oct 15, 2026

9luna233 commented on Oct 28, 2026

jamditis commented on Oct 30, 2026

Observed sequence (UTC)

Impact and expected behavior

Recovery update, October 30 (UTC)

Recurrence, October 30 (UTC)

Day-rollover check, October 30

Correction: browser restriction versus connector access, October 30

Assistant behavior and user impact

Separate occurrence: renewed PR approval rejected at task creation, October 30 (UTC)

WenyuChiou commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions