What causes "name={name!r}, domain={domain!r}, path={path!r}" in psf/requests?

Use jar.get('name', default) instead of indexing to avoid the exception when absence is expected.

psf/requests · error · KeyError

name={name!r}, domain={domain!r}, path={path!r}

Error message

name={name!r}, domain={domain!r}, path={path!r}

What it means

A KeyError raised by RequestsCookieJar._find() in src/requests/cookies.py when no cookie in the jar matches the requested name (and optional domain/path filters). _find is the internal lookup Requests uses to read cookie values; the error message echoes the search criteria (name, domain, path) so you can see exactly what was asked for.

Source

Thrown at src/requests/cookies.py:421

    ) -> str | None:
        """Requests uses this method internally to get cookie values.

        If there are conflicting cookies, _find arbitrarily chooses one.
        See _find_no_duplicates if you want an exception thrown if there are
        conflicting cookies.

        :param name: a string containing name of cookie
        :param domain: (optional) string containing domain of cookie
        :param path: (optional) string containing path of cookie
        :return: cookie.value
        """
        for cookie in iter(self):
            if cookie.name == name:
                if domain is None or cookie.domain == domain:
                    if path is None or cookie.path == path:
                        return cookie.value

        raise KeyError(f"name={name!r}, domain={domain!r}, path={path!r}")

    def _find_no_duplicates(
        self, name: str, domain: str | None = None, path: str | None = None
    ) -> str:
        """Both ``__get_item__`` and ``get`` call this function: it's never
        used elsewhere in Requests.

        :param name: a string containing name of cookie
        :param domain: (optional) string containing domain of cookie
        :param path: (optional) string containing path of cookie
        :raises KeyError: if cookie is not found
        :raises CookieConflictError: if there are multiple cookies
            that match name and optionally domain and path
        :return: cookie.value
        """
        toReturn = None
        for cookie in iter(self):
            if cookie.name == name:

View on GitHub ↗ (pinned to 414f0513c3)

Solutions

Use jar.get('name', default) instead of indexing to avoid the exception when absence is expected.
Print list(session.cookies) or session.cookies.list_domains() to see what was actually stored, and match the domain/path filters to it.
Ensure the request that sets the cookie actually ran first (login/handshake), and that you're using a Session so cookies persist across requests.
Use HTTPS if the cookie is marked Secure.

Example fix

# before
token = session.cookies['csrftoken']

# after
token = session.cookies.get('csrftoken')
if token is None:
    raise RuntimeError(f"csrftoken not set; jar has: {[c.name for c in session.cookies]}")

Defensive patterns

Strategy: try-catch

Validate before calling

# Check existence before removing/accessing a specific cookie
exists = any(c.name == name and (domain is None or c.domain == domain) and (path is None or c.path == path) for c in jar)

Type guard

def cookie_exists(jar, name, domain=None, path=None):
    return any(c.name == name and (domain is None or c.domain == domain) and (path is None or c.path == path) for c in jar)

Try / catch

try:
    jar.clear(domain, path, name)
except KeyError:
    pass  # cookie not present

Prevention

Catch KeyError when calling jar.clear() or deleting a cookie that may not exist
Iterate the jar to confirm exact domain/path values first — cookie lookup requires exact matches, and domains often carry a leading dot ('.example.com')
Prefer jar.get(name, default=None) over jar[name] when absence is expected

When it happens

Trigger: Iterating jar lookups after a request: session.cookies['csrftoken'] style access paths that route through _find, or calling internal helpers with a name the server never set. With domain/path arguments supplied, a cookie with the right name but different domain/path also raises this.

Common situations: Expecting a cookie the server only sets after login or on a different domain/subdomain (e.g. '.example.com' vs 'api.example.com'); Secure cookies dropped because the request was plain HTTP; redirects that consumed the Set-Cookie on an intermediate response; typo'd cookie names.

Related errors

AI-assisted analysis of psf/requests@414f0513c3 (2026-07-31). Data as JSON: /data/errors/2db9511a196b24c2.json. Report an issue: GitHub ↗.