Skip to content

Add browser profile support for authenticated fetch_html requests #38

@tcdent

Description

@tcdent

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:

  1. Direct access - Works when Chrome is closed, fails if Chrome is open
  2. Copy cookies - Copy the Cookies SQLite database to a temp profile before launching
  3. 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

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions