Reuse another tool stored session, never fork auth
Built a LinkedIn enrichment worker that piggybacks on a running Matrix bridge stored authentication rather than authenticating independently.
Many tools that interact with web services (Matrix bridges like mautrix-linkedin, IM clients, even CLI auth helpers) store their full session state in a local SQLite or JSON file. When building a parallel tool that wants to call the same service as the same user, READ that file instead of running a second auth flow — same IP, same cookie jar, same trail, and you inherit the existing tool auto-refresh of rotating tokens (JSESSIONID, lidc, etc.) for free. mautrix-linkedin specifically stores cookies as a Go http.Cookie array under user_login.metadata as JSON — open SQLite read-only, walk the array to rebuild the Cookie header, extract JSESSIONID with quotes stripped for the csrf-token header; one captured curl from a fresh DevTools session is only useful for the queryId hashes inside, never the cookies — those would create a second trail.
When integrating with a service that another tool on the same machine already authenticates to, check that tool storage (SQLite, ~/.config JSON, keychain entries) before designing a parallel auth flow — it is usually less work and always less rate-limit risk.