Hi! Thanks for building Verdict — I use it as my default browser tool with Claude Code and the token efficiency is great.
I want to suggest one feature, because logging into sites is the part I struggle with most. My current workflow for any site that needs auth looks like this:
verdict goto https://app.example.com
verdict handoff # open a visible browser
# type my email, type my password, solve MFA
verdict resume
verdict auth-save myapp
A day or two later, the saved profile is logged out and I have to repeat all the same steps. This happens often enough that it has become the most painful part of using the tool for me.
I think two changes would help a lot:
-
Use a persistent Chrome profile on disk. Something like chromium.launchPersistentContext('.verdict-data/chrome-profile/', ...) instead of a fresh context every time. A persistent profile keeps cookies, IndexedDB, service workers, and refresh tokens between runs automatically, so most sites would not need auth-save / auth-load at all.
I think this might also explain why my saved profiles expire so quickly. The current auth-save only stores cookies, localStorage, and sessionStorage. But services like Auth0 and Firebase often keep their refresh tokens in IndexedDB, which is not captured. So when I reload the profile later, the refresh token is gone and the site logs me out.
-
Allow loading a password manager extension into that profile. Mainly Bitwarden, but really any unpacked extension via --load-extension. Then on the rare occasions when I do need to log in, I can autofill the password instead of typing it, and I would not need to leave headless mode at all.
I know there are some constraints here. Extensions need either headed mode or Chrome's new headless mode (headless: 'new'). Pointing at the user's real Chrome profile is risky, because Chrome refuses to launch if it is already running, and there is a chance of corrupting the profile. So a separate .verdict-data/chrome-profile/ directory that the user sets up once seems like the safest approach.
Is this something you would consider adding? Or is there a reason the current design is intentional that I am missing? I am happy to test a branch if it helps.
Thanks again for the tool!
Hi! Thanks for building Verdict — I use it as my default browser tool with Claude Code and the token efficiency is great.
I want to suggest one feature, because logging into sites is the part I struggle with most. My current workflow for any site that needs auth looks like this:
A day or two later, the saved profile is logged out and I have to repeat all the same steps. This happens often enough that it has become the most painful part of using the tool for me.
I think two changes would help a lot:
Use a persistent Chrome profile on disk. Something like
chromium.launchPersistentContext('.verdict-data/chrome-profile/', ...)instead of a fresh context every time. A persistent profile keeps cookies, IndexedDB, service workers, and refresh tokens between runs automatically, so most sites would not needauth-save/auth-loadat all.I think this might also explain why my saved profiles expire so quickly. The current
auth-saveonly stores cookies, localStorage, and sessionStorage. But services like Auth0 and Firebase often keep their refresh tokens in IndexedDB, which is not captured. So when I reload the profile later, the refresh token is gone and the site logs me out.Allow loading a password manager extension into that profile. Mainly Bitwarden, but really any unpacked extension via
--load-extension. Then on the rare occasions when I do need to log in, I can autofill the password instead of typing it, and I would not need to leave headless mode at all.I know there are some constraints here. Extensions need either headed mode or Chrome's new headless mode (
headless: 'new'). Pointing at the user's real Chrome profile is risky, because Chrome refuses to launch if it is already running, and there is a chance of corrupting the profile. So a separate.verdict-data/chrome-profile/directory that the user sets up once seems like the safest approach.Is this something you would consider adding? Or is there a reason the current design is intentional that I am missing? I am happy to test a branch if it helps.
Thanks again for the tool!