[Bug]: Desktop In-App Browser control not authorized on 3.0.73 - controlAuthorized: false

[manugerahgunawan]

[Bug]: Desktop In-App Browser control not authorized on 3.0.73 — controlAuthorized: false despite Browser pane visible

Summary

On MiniMax Code 3.0.73.165 (Windows), opening the Browser pane inside the task view leaves the
ambient in-app-browser context at controlAuthorized: false. The Browser panel itself renders
and the user can navigate inside it, but the agent has no control path: attempting a Browser
operation returns the standard "Browser control is provided by a Browser Use Plugin with an
admitted Host Binding" guidance, and the control-in-app-browser skill is not provisioned to
the profile.

The 3.0.54 release notes describe "Browser Control: MiniMax Code can now operate continuously
inside the built-in browser" and 3.0.63 adds Browser Use 2.0 — i.e. this is supposed to work
out of the box on a fresh install. A clean install of 3.0.73.165 is missing something
required for the host binding gate to pass.

Steps to reproduce

1. Install MiniMax Code 3.0.73.165 on Windows (10/11, 64-bit).
2. Sign in.
3. Open the Browser pane from the right-side panel in any Coding-mode task.
4. Navigate to any URL inside the pane.
5. Ask the agent to operate the pane ("use the in-app browser to click Sign In", or any
   instruction that would trigger the browser tool).
6. Observe the agent responds with the disabled-binding guidance instead of acting.

Observed

• Ambient context block in the conversation:

  {"visible":true,"selectedTab":true,"controlAuthorized":false}
  

• Loading the built-in skill control-in-app-browser returns
  Local skill not found: control-in-app-browser.
• The agent does not receive the browser tool on any turn (it is never inserted into the
  tool set), so navigation/click/typing/screenshot through the pane is impossible from the
  agent side.

Expected

• On a fresh install of a build that ships Browser Control (3.0.54+), controlAuthorized
  should be true as soon as the Browser pane is opened, and the agent should have the
  browser tool available.

Environment

• MiniMax Code 3.0.73.165 (Windows 10/11)
• resources/app.asar size: 507 MB
• Profile state: a brand-new user profile (~/.minimax/) — plugins cache has 9 bundled
  skill plugins (diagram-design, performance-experts, excel, humanizer,
  marketing-skills, ppt, pm-skills, pdf, word), every one with hostBindings: 0.
• ~/.minimax/plugins/ contains only empty cache/ + marketplaces/ and a
  known_marketplaces.json whose single entry (claude-plugins-official) points at an
  installLocation that does not exist on this machine:
  C:\Users\manug\.mavis\plugins\marketplaces\claude-plugins-official (live profile is
  .minimax).

Investigation

Read the bundled code in app.asar directly (no source access — the public repo is an
issue tracker only). The Browser Control authorization gate is in two stages:

1. BrowserUseService.isProviderAvailable() (provider-resolving desktop adapter returns
   provider === 'electron-file-panel'):

   return provider && provider !== 'electron-file-panel'
       ? true
       : this.options.readConfig().filePanelBrowserEnabled === true;

2. resolveDesktopRequiredSkill(capabilities, allowedExtensionSkillNames, surface) requires
   exactly one match in capabilities.hostBindings with
   hostCapability.id === 'browser.use', version 1, exactly one required skill, and
   allowedSurfaces containing interactive.

Stage 1 passes either when beta.filePanelBrowser is true or when the online visibility
default is implicitly merged into the config the gate reads (the bundle documents this as
"ships ON by default in every environment"). Stage 2 has no documented default — there is
no browser.use binding in the bundled app, no browser-use plugin in the 9-plugin cache,
no browser-use plugin anywhere in ~/.minimax/, and zero results for browser paths in
the full 1046-file tree of the MiniMax-AI/MiniMax-Code-Plugins community registry.

This rules out:

• A missing or mis-set beta.filePanelBrowser — adding it (with the app fully restarted)
  does not flip controlAuthorized. So the online visibility default IS implicitly
  applied on this build.
• A user-config issue in general — this is a fresh profile.
• A legacy browser-use plugin collision (see openai/codex #46137 etc. for the mirror
  symptom in Codex) — no such plugin is installed.

What's left is a missing plugin. The bundle has the consumer (BrowserUseService,
LocalBrowserUseService, the browser.use host binding identifier, the
control-in-app-browser skill asset, the BROWSER_CONTROL_DISABLED_GUIDANCE injection, and
the BROWSER_PLUGIN_MANAGED 403 returned by admitQuestionnaireRequest for
request_feature_enable { featureKey: "browser-use" }) but never the producer (no
browser-use plugin manifest in the bundle, no community plugin of that name).

It looks like the Browser Use Plugin needs to be installed automatically on first launch
(by the Desktop app or by the marketplace updater) and isn't — possibly gated on the
marketplaces cache being populated, which is empty here, possibly gated on the registry
manifest being able to reach its installLocation (which is missing on this machine).

Workaround attempted

• Searched the Plugins tab for "browser", "chrome", "devtools" → only unrelated skills
  (agent-browser, browser-qa, browser-automation-testing) appear; none grant control.
• mcode plugin marketplace list returns an empty list. mcode plugin list --available
  returns no browser-related plugin.
• Adding beta.filePanelBrowser: true to ~/.minimax/config.yaml (with the app fully
  quit and restarted) did not change controlAuthorized.
• Cannot install a custom plugin manually: known_marketplaces.json's installLocation is
  a dead path; mavis mcp list/gh api style manual installs are not exposed in the UI.

Evidence

• app.asar references (count): browser-use/ ×43, control-in-app-browser ×56,
  hostBinding ×104, BROWSER_PLUGIN_MANAGED ×3, isProviderAvailable ×8,
  resolveDesktopRequiredSkill ×4, browser.use ×8, electron-file-panel ×8.
• Bundle comment for filePanelBrowser:
  "Both visibility fields are online, so it ships ON by default in every environment
  while retaining beta.filePanelBrowser: false as an emergency kill switch."
• Bundle code for the disabled-guidance marker (verbatim):
  "Browser control is provided by a Browser Use Plugin with an admitted Host Binding.
  Ask the user to enable or install that Plugin from Plugins; do not call
  request_feature_enable and do not claim that the legacy Browser Use switch can
  authorize control."
• GitHub issues for the analogous Codex failure (same architecture, same symptom):
  openai/codex #46137, #43776, #19365, #20678. None of these are about the MiniMax
  implementation directly, but they document the same class of failure when the Browser Use
  plugin is missing from a desktop install.

Suggested fix (for maintainers)

Either ship the Browser Use Plugin inside the app's own plugin cache
(~/.minimax/v2/plugin-cache/official/<plugin-name>/...), or document the install command
that an end user can run to register it. The Plugins marketplace catalog is unreachable on
this install (known_marketplaces.json points to a non-existent installLocation under
the legacy .mavis profile), so any marketplace-based discovery is currently broken.

[manugerahgunawan]

Config-flag update — 2026-09-23. Tested before filing: added beta.filePanelBrowser: true to ~/.minimax/config.yaml with the app fully quit, relaunched (MiniMax Code 3.0.73.165, ~110 s uptime post-restart, config.yaml LastWriteTime confirms the rewrite preserved the new line). Result: controlAuthorized stayed false. So the online visibility default IS implicitly applied on this build — that stage of the gate is fine — and the blocker is genuinely the missing browser.use host binding.

Local config file now reads:

beta:
  browserUseTooling: true
  filePanelBrowser: true

Reporting both lines here so this isn't re-investigated.