Repository navigation
0.3.8: Restore Chrome startup with persistent profiles
check_login could fail with connect ECONNREFUSED 127.0.0.1:<port> while a blank Chrome window remained open. The published package resolved chrome-launcher 1.2.2, which discovers Chrome's dynamic debugging port from the first matching entry in the profile's append-only chrome-err.log. Reusing a profile could therefore select a port from an earlier run.
The server now allocates an available loopback port and passes it explicitly to the launcher, avoiding discovery from historical log entries. The profile, login persistence, URL allowlist, request interval, session queue, and fetch budgets remain in place. The lockfile now resolves launcher 1.2.2 so source builds exercise the affected dependency.
Verification on Windows with Bun 1.4.2 and Chrome 154.0.8037.58:
- Focused regression: the allocated port is nonzero and released for a loopback listener.
- Live forum navigation completed in about six seconds after a Cloudflare challenge; the parser recognized the forum index and 237 sections.
- A fresh MCP stdio process using launcher 1.2.2 returned
loggedIn: truefromcheck_loginin 3.7 seconds.
These observations establish successful access for this local session. Other operating systems, networks, and production challenge configurations still need live verification. Close abandoned windows using the dedicated MCP profile before restarting; do not run multiple servers against the same profile.