Codex Desktop can assert visible app/tool success after backend-only changes, before foreground acceptance

[grtninja]

Summary

During a long-running Codex Desktop task, the user explicitly required a local desktop application's visible chat surface and integrations to work—not merely backend configuration changes. Codex repeatedly ran shell/backend commands and then stated that the visible tools were enabled, the live conversation was corrected, or the user could now see the requested state.

Screenshots taken immediately afterward showed that required integrations were still disabled or faulted, the provider/header state was wrong, Send could still be broken, and the requested useful output was not present. Codex later acknowledged that it had changed stored conversation/configuration flags without proving that the corresponding integration processes and live tool calls were healthy.

This is an evidence-gating defect: progress narration can claim a foreground-visible result before a foreground acceptance check has happened.

Environment

• Product: Codex Desktop
• Platform: Windows 11 Pro
• Subscription: ChatGPT Pro
• Workload: long-running repository and local-agent integration task
• Observed: July 23, 2026
• Target application: local desktop AI application; private integration names and repository paths omitted

Observed sequence

1. User requires real work and tool output to appear in a visible desktop chat surface.
2. User explicitly rejects backend-only receipts and asks Codex not to claim visibility without seeing it.
3. Codex runs backend commands or edits stored integration/conversation state.
4. Codex states that tools are enabled, the visible state is corrected, or the user can see the result.
5. Foreground screenshots show required integrations still disabled/faulted, a mismatched provider state, missing useful output, or a broken Send path.
6. Codex later retracts the claim and says the stored flags were changed before live integration health was proven.
7. The cycle repeats, consuming usage and destabilizing the target application.

Expected behavior

Codex should distinguish at least these states:

• configuration written;
• integration enabled in stored state;
• process/transport reachable;
• authentication/admission successful;
• tool inventory loaded;
• live tool call successful;
• foreground/operator-visible acceptance confirmed.

It must not use phrases such as fixed, working, visible, enabled, you can see it, or equivalent completion language unless the required evidence level has actually been reached.

For a task with an explicit visible acceptance contract, Codex should:

• run a foreground inspection, screenshot check, accessibility/UI probe, or target application's own live health/tool call before asserting success;
• state exactly which evidence was obtained;
• say plainly when it cannot inspect the target surface;
• treat backend-only configuration as an intermediate step, not completion;
• avoid modifying broad integration state merely to make toggles appear enabled;
• stop and produce a bounded failure report after repeated acceptance mismatches.

Suggested machine-readable progress contract

Each progress event should carry fields similar to:

• claimed_state
• evidence_type
• evidence_timestamp
• foreground_verified
• live_call_verified
• remaining_acceptance_checks

The UI should avoid rendering a success-style progress statement when foreground_verified=false for a foreground requirement.

Impact

• Users rely on false state claims and continue a broken workflow.
• Usage is spent correcting claims that should never have been made.
• Backend flags can diverge from live process and UI state.
• Broad configuration changes can break working integrations or the Send path.
• Trust is damaged because the agent narrates verification it did not perform.

Related reports

• Codex CLI marks turn complete while follow-up is still needed after progress message #27352 — turn/task can end after a progress message promises an action that never occurs.
• Codex Desktop auto-compaction completes but leaves long-running thread ~80% full, causing repeat compaction and usage waste #35032 — repeated compaction and usage waste in the same long-running failure class.
• Codex Desktop does not surface active OpenAI incidents or pause failure-prone long-running sessions #35037 — missing incident visibility and protective pause behavior.

This report is narrower than general hallucination: it concerns claims about an externally visible application state where Codex had an explicit acceptance requirement but had only performed backend/configuration work.

[github-actions]

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

• Codex can claim external-app configuration success without verifying the live postcondition or rolling back regressions #35039

Powered by Codex Action

[grtninja]

One additional acceptance requirement from the same incident: external-app configuration changes need a rollback contract, not only better success wording.

Before mutating stored plugin/integration state, Codex should capture a last-known-working snapshot. It should then change one integration at a time, validate the live message path and a real tool call, and automatically restore the snapshot if the change breaks an existing function such as Send. A failed integration should be quarantined individually rather than forcing the two bad extremes observed here: enable everything and poison the chat, or disable everything and leave an empty chatbot.

Suggested evidence fields:

• rollback_point_created
• configuration_written
• transport_reachable
• handshake_verified
• functional_call_verified
• foreground_verified
• regression_detected
• rollback_attempted
• rollback_verified

This keeps the issue's core invariant intact: backend/configuration work is intermediate evidence, not visible product success.

[grtninja]

A concrete local implementation pattern supports the state-separation contract requested here.

In grtninja/memryx-mx3-python-shim#255 (merged), an LM Studio/plugin bridge was changed so operator status no longer treated backend configuration as proof of a usable foreground path. The implementation split and surfaced:

• plugin mirror/install state;
• shim-hosted runtime/model state;
• bridge/route readiness;
• explicit recovery-command construction;
• selected model/route metadata;
• operator-facing readiness cards backed by live probes.

The slice was verified with a live renderer/plugin check plus focused suites: 73 Python tests, 35 Electron/window tests, and 17 React operator-surface tests. It also kept the bridge-only recovery path separate from broad runtime mutation.

This is not an upstream Codex patch, but it demonstrates the core remediation invariant in production code: configured state, visible state, route readiness, live probe success, and foreground/operator truth must be distinct values.

For Codex automation of external apps, I would encode that as a required transactional result object rather than prose:

configured_written
enabled_in_store
process_reachable
protocol_handshake_ok
tool_inventory_loaded
functional_call_ok
foreground_verified
rollback_available
rollback_executed

A success-style narration should be impossible unless the acceptance-required fields are true. If a functional call or foreground check fails, the result should stay partial/degraded, identify the exact failing integration, and either roll back or quarantine only that integration.