›_ Codex Issues
Codex Issues / #32568

Safety: agent misresolved a session-label rename as intent to close a Shopify store

Open 💬 2 comments Opened Jul 12, 2026 by twe-cloud

Summary

Codex misinterpreted a request to remove an incorrect session/access label as authorization to close a Shopify store. The surrounding context explicitly identified the canonical Shopify store and handle, yet the agent escalated a metadata naming correction into a destructive store-closure workflow.

No Shopify mutation executed because the user recognized the dangerous misinterpretation and manually interrupted the agent. Codex did not detect, prevent, or safely recover from the error itself. The agent had announced that it was proceeding to close the store and had begun setting up browser automation.

Context available to the agent

Immediately before the failure, the user provided:

  • Store display name: Ni Biashara
  • Verified store handle: ni-biashara-2
  • Shopify admin access confirmed
  • Selected text: ni-biashara-2

The user then referred to removing “Ni Biashara 1.” In context, “Ni Biashara 1” was the stale session/access label. The intended operation was to relabel the access session while preserving the underlying store handle, links, authentication, and affiliate integrations.

Actual agent behavior

The agent:

  1. Resolved “Ni Biashara 1” as a separate Shopify store without evidence.
  2. Asked for a .myshopify.com URL in preparation for closing it.
  3. After the user insisted it act, stated: “I’m closing the duplicate Shopify store Ni Biashara 1 and preserving ni-biashara-2.”
  4. Began initializing browser automation for a store-closure workflow.
  5. Did not stop itself or recognize the context conflict.
  6. Was stopped only because the user caught the error and interrupted the turn.

Expected behavior

For destructive actions involving external business systems, Codex should:

  1. Ground entity resolution in the immediately preceding session context.
  2. Distinguish UI/session labels from provider resource identifiers.
  3. Never convert a label rename into deletion/closure without direct evidence that the named object is a store.
  4. Require a verified destructive target identifier before entering a closure workflow.
  5. Preserve connected-store handles, OAuth sessions, billing, and affiliate integrations when the requested scope is access-label metadata.
  6. Prefer a reversible label correction when the wording and selected text indicate access alignment.
  7. Provide a safety barrier that does not depend on the user noticing and interrupting the mistake in time.

Potential impact

If the user had not intervened, closing or disconnecting the wrong Shopify store could have broken:

  • Affiliate tracking and merchant integrations
  • Storefront links
  • Shopify app authorizations
  • Product and order workflows
  • Revenue-generating business operations

This was a user-prevented near miss involving a customer-facing BUSINESS system.

Safety request

Please investigate entity resolution and destructive-action gating when Codex receives selected text plus inherited session context. A destructive provider action should not proceed when the target exists only as an inferred entity and conflicts with the known canonical resource.

No Shopify store, handle, link, authorization, or affiliate integration was changed solely because the user caught and interrupted the unsafe workflow before execution.

View original on GitHub ↗

2 Comments

rpelevin · 1 month ago

This looks like an entity-resolution failure that should be blocked before browser navigation, not repaired by another model turn.

I would require a typed target envelope for every destructive provider action:

  • provider and operation class;
  • resource type and canonical provider resource id;
  • identity source: user-supplied, provider-readback, or inferred;
  • requested scope and canonical arguments digest.

A display label or selected-text value should never fill the provider resource id. If the destructive target is inferred, missing, or conflicts with the current canonical resource, preflight should stop before opening destructive settings and ask for the exact target.

Regression cases I would keep:

  1. Renaming a session/access label cannot resolve to closing or deleting a provider resource.
  2. A bare continuation such as do it can confirm only the already displayed exact envelope; it cannot supply a missing resource type/id or widen the operation class.
  3. Changing operation, target, scope, or arguments after confirmation requires a fresh confirmation.
  4. Browser automation cannot navigate into a destructive workflow until the grounded envelope passes and is shown to the user.
  5. Interruption before execution records a no-effect outcome rather than an ambiguous partial success.

Boundary: architecture and regression-test feedback only. I did not reproduce this report or validate Codex, browser automation, Shopify behavior, implementation correctness, security, production readiness, official alignment, adoption, partnership, integration, customer interest, or Neura usage.

BGMLAI · 1 month ago

This needs a two-phase destructive-action protocol. Phase one resolves and displays a typed target from provider readback; phase two executes only when the resource id, resource type, operation, and user intent all match.

A selected label should never be promoted into a provider resource id. If the only evidence for the destructive target is model inference, the action should be ineligible for execution. For browser-driven business systems, the final page should also be re-read immediately before submission and compared with the approved target envelope, so a stale tab or navigation change cannot redirect the action.