-
Notifications
You must be signed in to change notification settings - Fork 3
Open
Description
Problem
The fetch_html tool currently launches a fresh headless Chrome instance without any user data. This means it can't access authenticated content on sites where the user is already logged in via their regular Chrome browser.
Proposed Solution
Add a config option to specify a Chrome user data directory:
[tools]
browser_user_data_dir = "~/Library/Application Support/Google/Chrome"
# Or a specific profile:
# browser_user_data_dir = "~/Library/Application Support/Google/Chrome/Profile 1"When configured, the headless browser would use --user-data-dir to access the user's existing cookies and session data.
Implementation Notes
Profile Locking
Chrome doesn't allow two instances to use the same profile simultaneously. Options:
- Direct access - Works when Chrome is closed, fails if Chrome is open
- Copy cookies - Copy the Cookies SQLite database to a temp profile before launching
- Dedicated profile - User creates a separate "codey" profile in Chrome that isn't used interactively
Security/Consent
Explicit configuration of this option serves as user consent to share their browser cookies with the agent. This should be documented clearly.
Default Paths
- macOS:
~/Library/Application Support/Google/Chrome - Linux:
~/.config/google-chrome - Windows:
%LOCALAPPDATA%\Google\Chrome\User Data
Use Cases
- Fetching content from sites requiring login (GitHub private repos, internal docs, etc.)
- Accessing paywalled content where user has a subscription
- Any site with personalized content based on login state
Metadata
Metadata
Assignees
Labels
No labels