Skip to content

Extension leaves chrome.proxy.settings active after being disabled, causing ERR_PROXY_CONNECTION_FAILED on all browsing #18

@shrijayan

Description

@shrijayan

Summary
When the extension is loaded unpacked and then Developer Mode is toggled off in the browser (or the extension is
otherwise disabled without being formally removed), the proxy policy it set via chrome.proxy.settings remains active
while the extension itself becomes invisible in chrome://extensions. Since the local proxy (127.0.0.1:57418) is no
longer being served by anything, the entire browser becomes unable to load any page with:

ERR_PROXY_CONNECTION_FAILED
There is something wrong with the proxy server, or the address is incorrect.

The user has no obvious recovery path from the UI — the extension isn't shown, so it can't be removed; and the system
proxy settings look fine because the override lives inside the browser's extension policy, not Windows.

Environment

  • Browser: Brave 147.1.89.141 (Chromium-based) on Windows 11
  • Loaded the extension unpacked via Developer Mode
  • After some time, Developer Mode was toggled off; the extension disappeared from chrome://extensions but its proxy
    policy stayed in effect

What I found in the profile

Inside User Data/Default/Secure Preferences:

"extensions.settings.": {
"location": 4,
"path": "…/ts-browser-ext",
"preferences": {
"proxy": {
"mode": "fixed_servers",
"server": "127.0.0.1:57418",
"bypass_list": "localhost,127.*"
}
}
}

Recovery required manually editing Secure Preferences (plus the corresponding protection.macs entries) to drop the
extension record.

Suggested fixes

  1. Clear the proxy policy when the extension is unloaded / suspended, e.g. in a chrome.runtime.onSuspend handler,
    chrome.management.onDisabled, or via chrome.proxy.settings.clear({ scope: 'regular' }) on teardown.
  2. Consider setting scope: 'regular_only' / session-scoped rather than fully persistent so a restart doesn't silently
    reapply the override.
  3. Detect unreachable 127.0.0.1:57418 at runtime and fall back to direct mode instead of hard-failing every request.
  4. Add a troubleshooting note to the README for users who get stuck in this state (manual steps to edit Secure
    Preferences, or the brave://net-internals/#proxy → re-apply flow, which by itself doesn't fix it since the policy is
    extension-owned).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions