DEV Community

linweidao
linweidao

Posted on

I Spent an Afternoon Making My Logged-In Browser an IDE Tool

The recurring friction in my AI-assisted workflow is not generating code. It is everything that happens after the code is written: opening the right browser profile, signing in again, finding the correct tab, and explaining to an agent which page it should use.

That is where citrolabs/ego-lite feels refreshingly focused. Its premise is simple: let an AI agent use a browser session that is already logged in, without taking over my normal browsing session. The project has also picked up serious community attention, with more than 7,000 stars added recently, so I wanted to test the workflow rather than judge it from the README.

Minimal setup

I started with a local checkout:

git clone https://github.com/citrolabs/ego-lite.git
cd ego-lite
npm install
npm run
Enter fullscreen mode Exit fullscreen mode

The final command is intentional. It shows the available package scripts instead of assuming a particular development entry point. After launching the documented local command, I kept ego-lite open beside VS Code and used it as a dedicated browser surface for agent tasks.

The useful part is the lack of a large configuration layer. I did not need to create a browser extension matrix, copy cookies manually, or maintain a separate automation profile. The setup is closer to “start the browser, then let the agent connect” than to a traditional automation stack.

Before and after

Before ego-lite, my Cursor or terminal-agent workflow often paused at authentication. I would either describe the page manually or create temporary scripts just to reach an already-authorized screen.

Afterward, the browser became another tool in the working loop:

  1. Open the required site interactively.
  2. Keep the session available in ego-lite.
  3. Ask the agent to inspect, navigate, or complete the narrow task.
  4. Review the result in the browser.

That removes a surprising amount of context switching. It also makes prompts shorter because I can refer to the visible application state instead of explaining every login and navigation step.

Practical verdict

I would keep ego-lite for local, supervised workflows where speed matters and the browser state is convenient. I would stay with vanilla Playwright or a clean automation profile for repeatable CI, security-sensitive tests, and anything requiring deterministic isolation. The simplicity is the feature—but it also means I would treat it as a focused desktop tool, not a replacement for a full test infrastructure.

Top comments (0)