›_ Codex Issues
Codex Issues / #22701

iOS Connections edit mode has no delete option for stale CLI Codex connection

Open 💬 5 comments Opened May 14, 2026 by johnsilvavlogs

What version of Codex CLI is running?

codex-cli 0.130.0

What platform is your computer?

macOS 26.3, build 25D125

Codex Desktop app:

  • CFBundleShortVersionString: 26.513.20950
  • CFBundleVersion: 2816

What issue are you seeing?

In the ChatGPT iOS app, under Codex -> Connections, a stale legacy CLI connection remains visible after moving to the native Codex Desktop integration. The CLI row can be toggled off, but entering Edit mode does not expose any delete/remove affordance for that row.

This leaves users with no visible way to remove old experimental/headless CLI remote-control connections after the native desktop integration is working.

Why this matters

The current UI makes the stale CLI entry look like an active or still-configured access path, even when local cleanup has removed the old bridge/process/config. It creates uncertainty about whether there are SSH/CLI leftovers or hidden remote-control access still present.

In this case, local cleanup verified:

  • No codex remote-control process was running.
  • No matching Codex remote-control LaunchAgent/LaunchDaemon remained.
  • No SSH/tunnel helper was present.
  • ~/.codex/config.toml no longer contained remote_control.
  • Local remote_control_enrollments could be cleaned to leave only the native Codex Desktop row.
  • Both state_5.sqlite and logs_2.sqlite passed pragma integrity_check.

Despite this, the iOS UI originally still showed the stale CLI connection and provided no obvious delete path in Edit mode.

Reproduction

  1. Before or during the native Codex Desktop mobile integration, enroll a Mac through the experimental/headless CLI path, for example codex remote-control.
  2. Later connect the same Mac through the native Codex Desktop integration.
  3. Open ChatGPT iOS -> Codex -> Connections.
  4. Observe both Codex Desktop and CLI entries.
  5. Tap Edit.
  6. Try to remove the stale CLI entry.

Expected behavior

Edit mode should expose a delete/remove/disconnect-for-this-entry action for stale or disabled CLI connections, or there should be a documented cleanup flow from the mobile UI.

Actual behavior

Edit mode does not show a delete/remove option for the stale CLI connection. The only obvious global action is Disconnect All, which is too broad because it would also disconnect the working native Codex Desktop connection.

Related context

This is related to, but distinct from, #22693. That issue covers a stale Codex run failed banner after bridge restart. This issue is specifically about stale connection management in the iOS Connections UI.

I am not attaching the screenshot here because it contains a personal local hostname, but the screenshot shows:

  • Codex Desktop connection enabled for the Mac hostname.
  • CLI connection disabled for the same Mac hostname.
  • Edit button present.
  • Disconnect All button present.
  • No delete affordance visible for the CLI row.

View original on GitHub ↗

5 Comments

johnsilvavlogs · 3 months ago

Correction from local follow-up: I restored the local codex-browser-use enrollment row because it appears to be an internal Browser Use/native in-app browser enrollment, not the visible stale CLI row. The visible stale CLI entry corresponded to the blank legacy enrollment row. After local cleanup, the blank legacy row is removed, while codex-browser-use and Codex Desktop remain locally. The iOS product issue remains the same: the Connections UI shows a stale/disabled CLI row but Edit mode exposes no per-row delete/remove affordance.

johnsilvavlogs · 3 months ago

Follow-up after checking the current OpenAI Codex docs and local plugin metadata:

  • Official docs describe the feature as Browser use and say to install/enable the Browser plugin; direct reference is @Browser. See https://developers.openai.com/codex/app/browser#browser-use and https://developers.openai.com/codex/app/settings#browser-use.
  • Local plugin metadata also has name browser, displayName Browser, and aliases including @browser-use; its skill selects the native in-app browser backend iab.
  • I removed only the stale remote_control_enrollments row named codex-browser-use; the bundled Browser plugin files remain installed under ~/.codex/plugins/cache/openai-bundled/browser/0.1.0-alpha2.

Current local enrollment table now contains only Codex Desktop, so the reported iOS stale CLI/extra connection is not backed by a local Browser plugin deletion.

sirmalloc · 3 months ago

@johnsilvavlogs I found a workaround if you need to get rid of old connections, it calls the server side endpoint to list / remove them: https://gist.github.com/sirmalloc/fefef0b65729d9644794a3c67d1a28b9

m-rousseau · 3 months ago

I have this issue but via my iphone. It has a stale connection to my macbook and makes it impossible to re-connect to the macbook

Snailflyer · 3 months ago

The key product issue is that Disconnect All is too coarse for a connection list that can contain different generations of access paths.

A stale legacy CLI row, a native Codex Desktop row, and an internal/browser-use enrollment should not share only one global destructive action. Each row needs its own identity and lifecycle affordance: type, host label, last seen, local vs account-backed, enabled/disabled/revoked, and a per-row remove action.

Without that, the UI cannot communicate the security boundary. A disabled stale row still looks like hidden access, while deleting everything is risky because it can remove the working native path too.