Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Windows: working Vivaldi connection reports Chrome identity; another chat says Vivaldi is not configured

Open
#52,348 0 comments 0 reactions 0 assignees View on GitHub

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

app browser bug windows-os
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:

  1. Install/enable the ChatGPT browser extension in Vivaldi using the desktop app's setup flow.
  2. Confirm Settings > Computer use shows Vivaldi installed and enabled.
  3. Inspect the available browsers through the supported unified browser-control API.
  4. Observe that the external connection reports name: "Chrome" and family: "chrome", with no Vivaldi entry.
  5. Select that connection by its returned ID and open/read https://example.com/: navigation and visible page inspection succeed.
  6. 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

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.