Chrome opens a new window for each command-line macro call (used to reuse same tab)

I am running UI.Vision macros via the command-line interface using the documented file:///…ui.vision.html?.. mechanism.

This has been working reliably for a long time, but after updating Chrome on Windows, the behavior changed.

Setup

  • UI.Vision Player Edition

  • Windows (multiple VMs, same behavior on all)

  • Chrome recently updated (issue did not exist on older versions)

  • Same setup still works on:

    • Ubuntu (Chrome)

    • Windows (Firefox)

Command-line call

Each macro is triggered via:
file:///C:/WC/uivision/ui.vision.html?macro=macroScripting_2026.04.14.json&direct=1&closeRPA=0&closeBrowser=0&continueInLastUsedTab=1&storage=xfile&savelog=logchromerpa_macro_1BDCEC101A9599DBFE1915D96AFD6FE2_2026_04_14.txt

This URL is passed to Chrome via command line (java wrapper, ProcessBuilder → chrome.exe).

Expected behavior (before Chrome update)

  • Chrome is already running with a specific profile

  • Each command-line call opens the macro in the existing browser session

  • UI.Vision continues in the same tab (via continueInLastUsedTab=1)

  • The flow works across multiple macro calls:

    • macro A → macro B → macro C
  • All actions happen in the same browser tab/session

Current behavior (after Chrome update)

  • Every command-line invocation opens a new Chrome window

  • UI.Vision runs inside that new window

  • The previous tab/session is not reused

  • As a result:

    • continueInLastUsedTab=1 becomes ineffective

    • consecutive macro calls do not operate on the same tab anymore

This happens consistently on Windows with the updated Chrome version.

Important observations

  • The issue does not occur:

    • on Ubuntu with Chrome

    • on Windows with Firefox

  • The exact same command-line URL and logic is used in all cases

  • No changes were made to the macro structure or invocation logic

Conclusion

It appears that newer Chrome versions on Windows changed how external chrome.exe calls are handled:

  • Previously: attach to existing browser instance/tab

  • Now: open a new window for each invocation

This breaks workflows that rely on:

  • repeated command-line macro calls

  • continueInLastUsedTab=1 to maintain session continuity

Question

Is this a known change or limitation in newer Chrome versions?

Is there a recommended way to:

  • force Chrome to reuse the existing window/tab when invoked via command line

  • or ensure UI.Vision continues in the same browser context across multiple command-line macro calls

At the moment, the only working workaround is to use Firefox or an older Chrome version.

Update: Localhost workaround partially improves behavior, but issue remains

I switched from file:// to a local HTTP server:

http://127.0.0.1:8080/ui.vision.html?macro=...&direct=1&closeRPA=0&closeBrowser=0&continueInLastUsedTab=1&storage=xfile&savelog=…

This improved the situation:

  • Chrome no longer opens a new window immediately
  • UI.Vision session persists longer
  • continueInLastUsedTab=1 works initially

However, after some time (not immediately), Chrome still opens a new window again.

Important observation:

  • The command that triggers the new window is NOT consistent
  • It can be any macro (click, executeScript, extract, etc.)
  • There is no single “offending” command
  • It appears to be a gradual context drift rather than a specific macro issue

Also observed:

This suggests:

  • UI.Vision may lose the intended tab context over time
  • continueInLastUsedTab=1 then follows the wrong context
  • eventually Chrome opens a new window on the next command-line call

Environment:

  • Windows + Chrome (latest) → issue present
  • Linux + Chrome → works
  • Windows + Firefox → works

Conclusion:
The localhost workaround improves stability, but Chrome on Windows still does not reliably reuse the existing browser context across repeated command-line invocations.

Question:
Is there a recommended way to ensure stable tab/context reuse for repeated UI.Vision command-line calls on Chrome (Windows)?

It seems to be chrome 147.0.7727.57 specific the current version from today seems not to have the problem :slight_smile: