Cloud browser approval cites superseded task restriction after explicit clarification

ChatGPT Bugs
1

Environment

ChatGPT assistant/task using the cloud Chrome browser to operate TradingView. I use Windows, but the affected chart actions are in the cloud browser; this is not established as a Windows-native problem. Exact model/backend build for the affected calls is not established.

Bug

Ordinary chart-editing actions are intermittently rejected before execution as resuming a stopped workflow, despite explicit later user authorisation and saved task-scope corrections.

An earlier instruction stopped automated price-data extraction. Some assistant-drafted wording used the broader term “TradingView collection”. I subsequently explicitly authorised rebuilding chart drawings and their chart-linked daily-close alerts, while keeping automated extraction stopped. The saved instructions were clarified and the existing operator reviewed the newer approval.

Expected: evaluate the exact chart action against the latest explicit scope, while keeping the separate extraction workflow stopped. If a restriction remains applicable, identify its scope and a supported review route.

Actual: some drawing operations succeed, then a later similar operation is rejected citing the old stopped workflow. Login and ordinary reads remain available. We stopped rejected actions rather than switching tools or executors to bypass them.

Reproduction / observed sequence

This is an observed sequence in an existing task, not a proven minimal reproduction:

  1. Stop automated price extraction.
  2. Explicitly authorise separate chart-drawing edits and daily-close alerts.
  3. Clarify the saved instructions to distinguish those workflows.
  4. Attempt ordinary chart operations: selecting a Ray tool, selecting an existing ray to edit an anchor, or opening the Object Tree.
  5. Observe intermittent success followed by a rejection referring to the earlier restriction.

Diagnostics

31 October 2026, all times UTC:

  • 21:57: saved scope clarification.
  • 21:59: Ray selection succeeded; that chart was subsequently saved and checked.
  • 22:16: selecting an existing ray was rejected as continuing an “explicitly stopped TradingView charting workflow”.
  • 22:32: further saved clarification separated scheduled read-only reviews from separately authorised chart implementation.
  • 22:34: the ray-selection/settings action succeeded.
  • 22:38: selecting a ray through the Object Tree was again rejected as continuing stopped collection after a denial.

The quotation is a short sanitised excerpt; instrument names, account details and private identifiers are omitted. The rejected operations did not execute.

Logarithmic charting had worked earlier, and several linear charts also completed. The timing coincided with a log-to-linear rebuild, but that does NOT establish that changing scale causes the problem. Earlier broad wording may have contributed; we cannot identify the exact instruction/revision used internally.

Has anyone encountered this retained-instruction conflict in the cloud browser? Is there a supported way to identify which instruction is being applied and reconcile explicit later scope corrections without deleting existing work or weakening security controls?