Puppeteer

It is the shortest road from a script to a real page, and the one most multi account work is written in. Here it never launches the browser itself, and understanding why is most of what you need.

Puppeteer is an open Node library that drives a Chromium browser over the browser's own control channel.

What the library is

It is a Node package that speaks the browser's control protocol directly. Because it speaks that protocol, it can take over a browser somebody else started.

Node and nothing else
The library is written for JavaScript and TypeScript, and there is no official edition of it for other languages.
Two packages, one library
One edition brings a browser of its own and one brings none. The road described here wants the edition that brings none.
It talks to the browser directly
Commands go down the browser's own channel, which is what lets it attach to a window it did not open.

Attaching it to a profile here

The app opens the profile and answers with an address. Your script connects to that address the way it would connect to any other browser.

1
Switch the local interface on
It stays off until you do it in the app, and the screen then shows the address and the token to carry.
2
Ask the app to start the profile
The call names the profile and carries the token, and the answer holds the socket address for that profile.
3
Connect to that address
The library attaches to the running window, and the tab already open is the first page your script gets.

Your browser right now

These come from the browser you are reading this in. A driven browser reports the first row as true unless the launch takes that tell away.

Votre machine, en ce moment

Automation flag: mesure sur votre machine
User agent: mesure sur votre machine
Platform: mesure sur votre machine

Lu dans votre navigateur et affiché ici. Rien n’est envoyé nulle part.

Launching versus attaching

The edition that carries its own browser would open that browser instead of your profile. Your fingerprint, your proxy and your cookies all live in the profile the app opens.

The engine is ours to launch
The launch arguments carry the profile seed, the proxy and the data directory, and the app assembles them.
The address belongs to one profile
On the main engine the browser writes it inside that profile's own directory, and it reaches no other profile.
The window is already furnished
A profile opens with its own start page, so a script meets an open tab rather than an empty browser.

What connecting switches on

The library switches two observable areas on as soon as it attaches. Those areas put hooks inside Chromium that page script is able to notice.

The flow builder inside the app never switches them on, which is the whole reason it exists next to this road.

Say it before the site does

A person who learns this from a site rather than from us does not come back. If the site you work with looks for those hooks, assemble the sequence in the app and keep the library for the work that is not watched.

Often confused with

Playwright
A younger library reaching three browser families and several languages. It attaches here by the same road.
The developer panel
The panel inside the browser speaks the same protocol. It is a person looking rather than a program acting.
A browser extension
An extension lives inside the page world and reaches only what the browser chooses to hand it.

What this does not do

It does not ship with ARMANOS. You install the library and keep it current yourself, and the app neither downloads it nor pins a version of it.
It does not open your profile for you. The edition that carries a browser would open that browser, and your profile would sit untouched with its own fingerprint and proxy.
It does not hide what it switches on. Two observable areas go on at connect, and a site looking for those hooks will find them whatever the fingerprint says.
It does not outlive the window. The address dies with the profile it belongs to, so a long running script asks the app for a fresh one each time.

Check it

Each line above is a file you can open and a stand that holds it.

The worked example that starts a profile and connects to it: apps/web/test/страница-автоматизации.js
The launch arguments that carry the seed, the proxy and the directory: apps/desktop/src/lib/forkEngine.js
The automation flag is read from a real page in the real engine: apps/desktop/test/webdriver-flag.js
The route that starts a profile and answers with its address: apps/desktop/src/lib/local-api.js · apps/desktop/test/local-api-gate.js

Questions

Which edition of the library do I install?: The one that carries no browser of its own. The other downloads a browser and opens that, and none of your profile settings would apply to it.
Does the app have to be open?: Yes. The address belongs to a profile window, and the local interface that hands it out is part of the app.
Can one script hold several profiles at once?: Yes, up to the open limit. That number is worked out from the memory of your machine, you can set it yourself, and a start past it comes back as a refusal that names how many profiles are already open.
Does driving a profile set the automation flag?: Opening a control channel would, and a launch switch clears it again. The value is read back from a real page in the real engine rather than assumed.
Can the run happen with no window?: Yes. A single start can be asked for without one, and with nothing asked the profile's own setting decides.

Next to this

Connect your script to a real profile

Switch the local interface on, start a profile from code, and attach to the address that comes back.

Download ARMANOS See the examples