Windows: working Vivaldi connection reports Chrome identity; another chat says Vivaldi is not configured
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 22/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript
- Domain
- devtools
Research direction
The payload names no source files. Start from the cua.listBrowsers() inventory and the family field it returns, then trace how the external extension connection gets its name, across the native-host manifest diagnostic and the Settings > Computer use Vivaldi entry. Reproducing needs a Windows machine with Vivaldi and the ChatGPT extension. Done means a Vivaldi-owned connection reports name: "Vivaldi" and family: "vivaldi", with a test for a Vivaldi-only setup. The root cause is not yet located, so this is not a good first pick.
Written by the indexing model from the issue text.
Description
What version of the Codex App are you using (From "About Codex" dialog)?
Windows package: OpenAI.Codex 26.1002.7124.0 (verified on 2026-10-09).
Desktop app internal version and bundled browser/chrome/unified-computer-use plugins: 26.1002.52244.
The app's updater reported up to date during the same troubleshooting session.
What subscription do you have?
Not provided for this report.
What platform is your computer?
Microsoft Windows NT 10.0.26300.0, x64.
Vivaldi 8.2.4133.84 (verified from the installed executable).
Agent environment: Windows native.
What issue are you seeing?
Vivaldi is installed, its ChatGPT browser extension is enabled, and the desktop app's Computer use settings show Vivaldi as installed and enabled. Browser automation through that connection works, but the supported unified browser inventory identifies the connection as Chrome:
await cua.listBrowsers();
Sanitized external-browser entry observed on 2026-10-09:
{
"id": "3",
"name": "Chrome",
"family": "chrome",
"type": "extension"
}
No entry with family: "vivaldi" is returned. The other entries are the in-app browser and MCP Apps.
This is not only a cosmetic problem: after the working Vivaldi connection was established, the user asked another chat to use Vivaldi, and that chat responded that Vivaldi was not configured. This separate-chat symptom is user-reported; its full transcript and exact tool-selection decisions have not been inspected.
What steps can reproduce the bug?
Observed sequence in this installation:
- Install/enable the ChatGPT browser extension in Vivaldi using the desktop app's setup flow.
- Confirm Settings > Computer use shows Vivaldi installed and enabled.
- Inspect the available browsers through the supported unified browser-control API.
- Observe that the external connection reports
name: "Chrome"andfamily: "chrome", with no Vivaldi entry. - Select that connection by its returned ID and open/read
https://example.com/: navigation and visible page inspection succeed. - In another chat, ask to use Vivaldi: the user reports that the assistant says Vivaldi is not configured.
Independent read-only process ownership verification established that the connected host is owned by Vivaldi:
extension-host.exe -> cmd.exe -> vivaldi.exe
The native-host manifest diagnostic returned correct: true during the same troubleshooting session. Google Chrome is not installed in this environment.
What is the expected behavior?
The available-browser inventory should identify a Vivaldi-owned connection consistently as Vivaldi, including family: "vivaldi". A new chat explicitly asked to use Vivaldi should discover and use that connected browser rather than falsely report missing configuration.
Browser identity should be consistent between Computer use settings, the extension handshake/inventory, and chat selection. Please add coverage for a Vivaldi-only external-browser setup on Windows.
Additional information
The concrete verified defect is the mismatch between a Vivaldi-owned working connection and its reported Chrome name/family. A causal link to the separate chat's refusal is plausible, but not yet proven. We have not established whether the incorrect identity originates in extension detection, the native bridge, or later discovery.
Earlier in this troubleshooting session, native Windows marketplace source paths had to be corrected from stale WSL/noncanonical paths. The built-in browser and Vivaldi automation subsequently became functional. This is therefore not claimed as a clean-install reproduction. No browser/runtime code or extension code was patched to change browser identity.
Related, but not necessarily the same defect: https://github.com/openai/codex/issues/32442 (Chrome selection binding to Brave on Windows).
Official documentation lists Vivaldi as a supported browser selectable by name:
https://learn.chatgpt.com/docs/chrome-extension
Only this sanitized report is submitted. No private tab lists, profile names, local usernames/paths, connection instance identifiers, raw logs, or chat transcripts are included.
- Dominant language
- Rust
- Stars
- 130k
- Forks
- 20.5k
- Avg merge
- 1m
- Merged PRs (30d)
- 996
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
bug CLI documentation
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
openai/codex#56630 · 3 comments · 3 reactions ·
Maintainers usually reply within 1 day
-
bug CLI connectivity
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
openai/codex#56616 · 3 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
app enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
openai/codex#56578 · 1 comment ·
Maintainers usually reply within 1 day
-
app enhancement session
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
openai/codex#56420 · 1 comment ·
Maintainers usually reply within 1 day
-
install.sh: standalone release pruning always skipped on macOS because `lsof +D` exit status 1 is treated as an error when matches are foundPossibly taken @akhil9tiet claimed this today. Openbug CLI
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
openai/codex#56412 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
checkpoint/verify/rebuild_indexes on a thread holding a WriteTransaction deadlock instead of INT-001Openbug known-issue
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
project-minigraf/minigraf#734 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 4 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
bitcoindevkit/electrum_streaming_client#57 ·
Maintainers usually reply within 2 days