[model-behavior][macOS] Identical GPT-5.6 Sol / Full access sessions inconsistently execute live brokerage orders

Summary

Codex behavior for a high-impact financial action is inconsistent across Macs that the user reports are configured identically.

The user reports that GPT-5.6 Sol with extra-high reasoning and Full access on several other Macs successfully used a fixed-scope Webull executor to preview and then submit a production securities order. On this Mac, the same stated model/reasoning/permission setup refuses to invoke any live place, replace, or cancel operation, even though the local Webull SDK, production endpoint, credentials, terminal access, and fixed CLI are working.

The concern is not simply that one session refused. The safety-critical bug is that some same-product instances reportedly perform a live securities mutation while another refuses, and the user cannot determine which governing rule differs.

Environment

• ChatGPT/Codex desktop app: 26.814.41957 (build 6744)
• Bundled Codex CLI: 0.148.0-alpha.15
• Separately installed Codex CLI: 0.144.1
• OS: macOS 14.6.1 (23G93)
• Model: GPT-5.6 Sol
• Reasoning effort: extra high
• Permission mode: Full access
• Local Codex memories: enabled on this host
• Webull SDK: webull-openapi-python-sdk 2.0.19

No credentials, tokens, account numbers, or full order identifiers are included in this report.

Verified on the affected Mac

1. The Webull production endpoint and authentication work for read-only account and order-detail calls.
2. A production NKE limit order existed in state SUBMITTED with filled_quantity=0 when queried. This confirms that a real order was present, but does not independently prove which Codex instance submitted it.
3. The current session had a local memory derived from an earlier PLTR short-sale refusal.
4. The agent initially cited that old memory as a direct reason for refusing the NKE request.
5. After an explicit correction was added stating that the PLTR case must not be generalized to all Webull requests, the agent continued to refuse, now citing a separate execution boundary.
6. Full access, production authentication, exact CLI capability, and a duplicate-order guard were all present, so the refusal was not caused by missing shell/network permissions or missing credentials.

User-reported behavior on other Macs

The user reports that other Codex installations using the same account, GPT-5.6 Sol, extra-high reasoning, and Full access:

1. Received an exact order authorization.
2. Called a non-submitting preview.
3. Used a one-time fixed-scope executor rather than an arbitrary trading script.
4. Called the production place_order() method.
5. Queried order detail and correctly reported SUBMITTED rather than FILLED.

This report labels those cross-device details as user-reported because this Mac cannot inspect the hidden context or logs of the other devices.

Steps to reproduce

1. On Mac A, start a new Codex task using GPT-5.6 Sol, extra-high reasoning, and Full access.
2. Provide a fixed-scope Webull CLI with valid production authentication.
3. Explicitly authorize an exact order and request preview, submission, and post-submit status verification.
4. Observe that the agent may invoke the production mutation and report SUBMITTED.
5. On Mac B with the same stated model/reasoning/permission configuration and equivalent CLI/authentication, repeat the request.
6. Observe that the agent refuses to invoke the mutation.
7. Ask for the precise refusal source. The explanation may move between local memory, product/system instructions, and an unspecified execution boundary.

Expected behavior

High-impact financial mutations should have one consistent, centrally enforced behavior across Codex installations:

• If Codex must never submit securities orders, every instance should refuse consistently before credential handling, and the UI should identify the governing product policy.
• If an explicitly authorized, fixed-scope workflow is permitted, the authorization requirements should be documented and applied consistently.
• Local memory should never create, remove, or masquerade as a product safety boundary.
• Full access should remain clearly described as a technical sandbox/approval setting, not as authorization for every task type.

Actual behavior

The user reports successful live brokerage submission by some instances, while this instance refuses under the same visible settings. The refusal explanation is not stable or inspectable and was initially influenced by an unrelated historical memory.

Impact

Severity is potentially high:

• Inconsistent execution of live securities orders can create direct financial risk.
• A user cannot predict whether a fresh Codex installation will execute or refuse the same mutation.
• Local memory can make the apparent reason misleading.
• The product provides no visible diagnostic showing whether the difference comes from product policy, system/developer instructions, account configuration, or memory.

Suggested improvements

1. Centralize and uniformly enforce the rule for brokerage order mutations.
2. Expose a structured refusal category such as product_policy, managed_requirement, missing_auth, tool_unavailable, or insufficient_order_parameters.
3. Prevent local memory from being treated as a normative authorization or prohibition.
4. Add an auditable event when an agent calls a live brokerage mutation.
5. Provide a cross-device diagnostics view showing model, reasoning effort, permission profile, managed requirements, relevant skills/plugins, and whether local memory influenced the decision.

Start with the reproduction steps using the stated Codex desktop and CLI versions, Full access, and fixed-scope Webull CLI, then compare the refusal source and local-memory influence across Macs. Done means the governing behavior is consistent and the report can identify whether policy, managed requirements, authentication, tool availability, or order parameters determined the outcome.