LowCodeStacks™
Sign in

Power Automate desktop "Failed to assume control" in Chrome or Edge

A desktop flow can't take over Edge, Chrome or Firefox. Run the troubleshooter, then fix the extension, slow launch, Windows user or profile, or use WebDriver.

Power AutomateFix a problem11 min read

Checked against Microsoft Learn · 7 sourcesPosted by the Maker DeskHow we write guides

Your desktop flow stops at its first browser step. A Launch new Microsoft Edge, Launch new Chrome or Launch new Firefox action fails, and Power Automate for desktop says it failed to assume control of the browser. In plain words, the desktop app opened the browser, or tried to, but couldn't connect to it, so none of the web actions after it can run. Microsoft documents four causes: the browser extension isn't working, the browser starts more slowly than the action waits, a different Windows user started the browser, or two sessions are fighting over one browser profile. Run the troubleshooter first, then work through the causes below. If nothing helps, newer versions can drive the browser through WebDriver instead of the extension.

What are you seeing?

Work down the list until the flow can control the browser
  1. Step 1Run the troubleshooter's UI and web automation check
  2. Step 2Reinstall the browser extension, then restart the browser
  3. Step 3Raise both launch timeouts, or launch and then attach with retries
  4. Step 4Start the browser as the same Windows user
  5. Step 5Give each session its own browser profile folder
  6. Step 6Switch the Launch action to WebDriver (version 2.62 or later)

What the error means

Microsoft's troubleshooting page shows the message in three forms, one per browser:

  • Failed to assume control of Microsoft Edge (Internal error or communication failure).
  • Failed to assume control of Chrome (Internal error or communication failure).
  • Failed to assume control of Firefox (Internal error or communication failure).

By default, Power Automate for desktop talks to these browsers through its browser extension. Each Launch action has a Browser interaction method setting, and its default is Browser extension. The extension in turn talks to a small helper program on the machine, PAD.BrowserNativeMessageHost.exe, with one copy running per browser type. If the extension, the helper or the timing breaks down, the action gives up with this message. Microsoft's extension page notes that other browser actions can fail with the same message at run time, not only the Launch actions.

The message says nothing about which cause you have, so check them in order.

Start with the troubleshooter

Microsoft's first step for this error is the troubleshooter built into Power Automate for desktop. It doesn't need you to sign in.

  1. In the Power Automate for desktop console or the flow designer, open Help > Troubleshooter. Build 2511 (installer version 2.62) also added it to the Windows Start menu.
  2. Run the Troubleshoot UI/Web automation issues diagnostic.
  3. When the check finishes, select Fix for each problem it reports.
  4. Run the flow again. If it still fails, go on to the causes below.

Causes and fixes

The browser extension is missing or not running

Signs: every run fails at the Launch action. When you start the recorder or the UI element picker on a web page, Power Automate for desktop asks you to get the extension. The extension can also look installed and enabled in the browser and still not run.

Fix:

  1. In the flow designer, go to Tools > Browser extensions and install the extension for the browser your flow uses.
  2. If it already looks installed, remove it and install it again anyway.
  3. Close the browser completely and open it again.

Check that you have the right extension. For Power Automate for desktop 2.27 or later, it's the one named Microsoft Power Automate. Version 2.26 or earlier uses Microsoft Power Automate (Legacy). Install only one of them.

If the error stays, check the helper program. Close every window of that browser, open it again, and look for PAD.BrowserNativeMessageHost.exe on the Details tab of Windows Task Manager. If it isn't running, the browser can't reach Power Automate for desktop. Microsoft's extension troubleshooting page lists the usual reasons:

  • A browser policy blocks it. Look for the NativeMessagingBlocklist policy at edge://policy/ or chrome://policy/. If it blocks all native messaging hosts, your admin can allow Power Automate's host in the NativeMessagingAllowlist policy. The Microsoft Store (MSIX) version also needs the NativeMessagingUserLevelHosts policy turned on.
  • Command Prompt is blocked. If Group Policy, Intune or a registry setting stops cmd.exe from running, the browser can't start the helper.
  • The extension is in more than one browser profile. Remove it from every profile, then install it only in the profile the flow uses.
  • Two installations. Having both the MSI and the Microsoft Store versions of Power Automate for desktop on one machine can stop the extension connecting.
  • Something else in the browser interferes. Try turning off your other extensions. Also turn off the browser setting that keeps apps running in the background after you close it, and Startup boost in Microsoft Edge.

Policies, the registry and installations belong to whoever manages the machine. Give them Microsoft's page from the Sources list below, which has the exact policy values and registry paths.

The browser starts slower than the timeout

Signs: some runs fail and others work, with nothing changed in between. The browser takes longer to start than the Launch action waits, so the action tries to take control before the browser is ready.

Both waits on the Launch actions default to 60 seconds: Timeout, for the browser to open, and Timeout for webpage to load. Microsoft gives three fixes. Try them in order.

Fix 1: wait longer. In the Launch action's Advanced section, raise both Timeout for webpage to load and Timeout. Microsoft's example is 120 seconds each.

Fix 2: launch, then attach with retries.

  1. Add a Launch action with Launch mode set to Launch new Instance and a simple starting address as its Initial URL.
  2. Open that action's On error settings, set Continue flow run to Go to next action, and save, so a failed takeover doesn't stop the run.
  3. Add a second Launch action for the same browser. Set Launch mode to Attach to running instance, attach to the tab by URL, and give it the address from step 1. Make it produce the same browser variable as step 1.
  4. In the second action's On error settings, turn on Retry action if an error occurs. Microsoft's example is 20 tries, 5 seconds apart.
  5. Add a Go to web page action that sends that browser variable to the page the flow really needs.

When it attaches by URL, Power Automate for desktop looks for an exact match of the address for the first half of the timeout, then accepts a partial match for the rest.

Fix 3: launch, wait, then attach. As in fix 2, but put a Wait action between the two Launch actions instead of retrying the second one. Microsoft's example is 90 seconds; adjust it to your machine.

A different Windows user started the browser

In version 2.38 and later, Power Automate for desktop can't take control of a browser that was started by a different Windows account from the one running the desktop app. Microsoft says this can happen in attended and unattended runs. The fix is to make sure the same Windows account starts both. For the session rules that unattended runs follow, see desktop flow connection not found.

Two sessions share one browser profile

Signs: the browser doesn't appear, or it opens on the first run and closes straight away on later ones.

When Microsoft Edge or Google Chrome starts, it checks whether another running copy already uses the same profile folder on disk. If one does, the new copy quits at once. So when the same user is signed in to several sessions on one machine, only one of those sessions can open the browser.

Microsoft's workaround is to start the browser from the flow with a profile folder of its own. Microsoft's example uses a Run application action that starts msedge.exe with this command-line argument, pointing at a folder you choose; its folder sits on the desktop:

text
--user-data-dir="<path to a folder of its own>"

Microsoft's page stops at starting the browser this way. It doesn't say how the flow should then take control of that window, so test that step on your machine before you rely on it.

Tip

Flows that run in picture-in-picture have a related setting. The Launch actions have a User data folder option for picture-in-picture runs. If you set it to Browser default, the browser can't be open on the desktop and in picture-in-picture at the same time.

General checks

If none of the causes fits, Microsoft's troubleshooting page lists these last checks:

  • The system environment variable ComSpec exists, with the value C:\WINDOWS\system32\cmd.exe.
  • For Chrome only, the exit_type value in the file %localappdata%\Google\Chrome\User Data\Default\Preferences is set to normal.
  • You've cleared the browser's cache and cookies by hand and restarted it.

Microsoft's extension troubleshooting page adds one more: look in Windows Event Viewer, under Windows Logs > Application, for errors from Power Automate for desktop.

Switch to WebDriver instead of the extension

From installer version 2.62 (build 2511), WebDriver is generally available. It's a second way for Power Automate for desktop to drive Edge, Chrome or Firefox, and it doesn't use the browser extension at all. Microsoft's troubleshooting page offers it as the alternative when this error won't go away.

  1. Find your browser's version: edge://settings/help in Edge, chrome://settings/help in Chrome, or about:support in Firefox.
  2. Download the matching driver from the browser maker: msedgedriver.exe for Edge, chromedriver.exe for Chrome or geckodriver.exe for Firefox. Only 64-bit (x64) drivers are supported. For Edge and Chrome, the first three parts of the version number typically have to match.
  3. Create a folder named WebDrivers in %LocalAppData%\Microsoft\Power Automate Desktop and copy the driver file into it. Don't rename the file or put it in a subfolder.
  4. In each Launch action, set Browser interaction method to WebDriver.

Know its limits before you switch:

  • It can only attach to browsers the flow itself launched, not ones opened by hand.
  • A child flow can't attach to a browser its parent launched this way unless the parent passes the browser in as an input.
  • On a slow web server, it might not respect the timeout in Wait for web page to load.
  • It doesn't work if a browser policy forces users to sign in to the browser.
  • Running browser automation in parallel in a parent and a child flow might behave erratically or fail.
  • It doesn't support Internet Explorer.

Do

  • Run the troubleshooter's UI and web automation check before changing anything by hand.
  • Reinstall the extension even when it looks enabled.
  • Use launch, attach and retry for a browser that starts more slowly than the Launch action waits.

Don't

  • Don't install both the current and the Legacy extension, or the extension in several profiles.
  • Don't change browser policies or the registry yourself on a managed machine; give your admin Microsoft's page.

For web steps that break when a page changes, rather than at launch, see UI elements that survive changes.

Sources

Add LowCodeStacks as a preferred source on Google

Did this fix it?

Comments

No comments yet. Share what worked for you.

Sign in to comment. Comments show under a display name you choose, never your email.