Linkedin Control

LinkedIn Control

LinkedIn is the one major surface that refuses every normal extraction route. A plain request gets HTTP 999 with an authwall body no matter which user agent you send, so curl, WebFetch, and every headless fetch return nothing usable. The reflex is to give up and buy a data vendor.

The way through is that the block is on anonymous access, not on the page. Inside a browser that already holds the user's session, LinkedIn is an ordinary web application that can be read, navigated, and operated. This skill is the map of that application as it actually exists, written from live probing rather than from selectors copied out of old blog posts.

One idea underneath everything here: you are not scraping a site, you are operating a logged-in application on behalf of its owner, and the whole craft is addressing the right element and stopping before the irreversible click.

Control plane

This skill owns how LinkedIn is addressed, read, and operated, plus the safety gate on anything that leaves the account. It does not own message wording, which belongs to the user's own voice and drafting skills, and it does not own campaign strategy or list building.

The rule that governs every write path, adopted after a real misfire described below:

The agent reads LinkedIn. The human clicks the buttons that other people can see.

Reading, navigating, extracting, and drafting need no permission. Anything that becomes visible to another person, meaning an invitation, a message, a comment, a reaction, a post, a follow, or an accept, requires the user's explicit approval for that specific action in that specific turn. Approval for one send is never approval for the next one.

Step 0: use a surface that carries the session

Four browser surfaces commonly exist in these runtimes and they are not interchangeable. Only some of them carry the user's LinkedIn cookies.

With the AppleScript surface, return location.href inside every evaluated payload and assert it before trusting the result, because it reads whatever tab happens to be frontmost and will happily hand you a different person's page.

Step 1: probe before you select, every time

LinkedIn is mid-migration between two front-end stacks and the same account sees both on different routes on the same day. Verified live on 2026-08-17:

• The new stack renders inside an open shadow root on div#interop-outlet. Plain document.querySelector finds nothing there. Class names are hashed into forms like _77e57c5d _3f9c3a5c, so every class-based selector ever published for LinkedIn is dead. Seen on the feed, My Network, search results, and profiles.
• The classic Ember stack is ordinary light DOM with the old readable class names such as msg-form__contenteditable and li.msg-conversation-listitem. Seen on messaging and on /recent-activity/.

So never assume. Run the probe first, then choose selectors based on what it reports:

({
  url: location.href,
  newStack: !!document.querySelector('#interop-outlet'),
  scroller: !!document.querySelector('main#workspace'),
  h1s: document.querySelectorAll('h1').length,
})

h1s is usually 0 on profiles, which is why the common "find the heading, then scope to its container" trick finds nothing. The real scroll container on the new stack is main#workspace with its own overflow, so window.scrollTo(0, 0) is a no-op and in-page scrolling must target that element.

Load scripts/li-probe.js into the page once per tab and you get __deep(selector), which queries through shadow roots, plus the targeting helpers used below. Everything in this file assumes it is loaded.

Step 2: the addressing ladder

Use the highest rung that the page offers, and never drop to a lower rung to save effort.

1. componentkey with a member URN. The strongest handle on the new stack, because it is machine-readable identity rather than text. A connect control carries componentkey="ConnectButtonstate:invitation:urn:li:member:<MEMBER_ID>_connect", and the profile top card is section[componentkey*="Topcard" i], which matches exactly one element.
2. Person-scoped aria-label. LinkedIn labels most person-level controls with the person's name, which is what makes safe targeting possible at all: Invite <Full Name> to connect, Withdraw invitation sent to <Full Name>, Accept <Full Name>'s invitation, Ignore an invitation to connect from <Full Name>, Follow <Full Name>, Open control menu for post by <Full Name>. Note that the possessive uses a curly apostrophe (U+2019), so match loosely on that character.
3. href substrings. a[href*="/in/"], a[href*="/company/"], a[href*="/sales/lead/"]. Reliable for harvesting, useless for buttons.
4. Container scoping plus visible text. For controls LinkedIn leaves unlabelled, such as Comment and Repost, anchor on a labelled sibling to find the post container and search only inside it. scripts/li-probe.js exposes __postBox(name) for exactly this.
5. Raw coordinates. Last resort only. Click coordinates are in screenshot pixel space, which is not the same as CSS pixel space when the screenshot is scaled, so a rectangle read from getBoundingClientRect() will be off by the scale factor and land on the wrong element. When you must click, prefer el.focus() or el.click() from JavaScript, both of which LinkedIn's handlers accept.

The wrong-person hazard, which is the single most important thing in this file

On a profile page there are typically a dozen controls whose visible text is exactly Connect, because the "More profiles for you" and "People you may know" rails each carry their own. Those rails are inside an <aside> that is itself nested inside <main>, so scoping to main does not exclude them, and DOM order puts rail cards near the top, so taking the first match selects a stranger.

This is not hypothetical. Matching on button text scoped to main and taking .first sent invitations to two strangers from the sidebar and they had to be withdrawn by hand. Reproduced again during the verification for this skill: on one profile the only aria-label containing "to connect" that a naive query returned belonged to a sidebar suggestion, not the profile owner.

The safe procedure, and the only one this skill endorses:

1. Read the intended person's name and member id from the top card.
2. Select by componentkey member id and require aria-label === "Invite <Owner Name> to connect".
3. Reject any candidate with an <aside> or rail heading ancestor.
4. Filter to visible elements, because the same control appears two or three times including a hidden copy at zero width and a sticky-header copy.
5. If the checks disagree with each other, raise and stop. Never guess, and never fall back to "the first one".

Also note that get_by_role("button", name="Connect") returns zero matches, because the aria-label overrides the accessible name, and that on the sent-invitations page the withdraw control is an <a> rather than a <button>, which is why searching for a button whose text is "Withdraw" fails.

Reading LinkedIn

Reading is the high-value, low-risk half of this skill and it needs no approval.

Entry points that work. Profiles at /in/<slug>/, activity at /in/<slug>/recent-activity/all/, companies at /company/<slug>/about/ and /people/, people search at /search/results/people/?keywords=..., company search at /search/results/companies/?keywords=..., the inbox at /messaging/, invitations at /mynetwork/invitation-manager/received/ and /sent/, and Sales Navigator at /sales/.

Skip /search/results/all/. The combined tab leads with Jobs and Posts and frequently returns neither the person nor the company you searched for, while the typed verticals work first try.

Never guess a company slug. A wrong slug silently redirects to /company/unavailable/ while navigation still reports success, and the tell is that text extraction then fails with "No text content found". Resolve the real slug through company search first. One real case had the obvious guess wrong and the actual slug carried an extra suffix.

Judge success from the page, not from the navigate call. Immediately after navigating, the tab title is still the bare hostname and resolves only on a later call, so "Navigated to ..." tells you nothing about whether the app rendered. Wait two to three seconds, then read, then judge from the returned title and URL.

Extraction order. Whole-page text is the cheapest and usually enough for profiles, search results, and inboxes. The accessibility tree is best when you need refs and labels, though it reports many anonymous buttons on the new stack because the label and the role often sit on different elements. In-page JavaScript is the most precise and is required for anything inside the shadow root.

Trim the boilerplate. Every profile extraction carries roughly 1.2 KB of recommendation cards, footer links, and a thirty-entry language selector. Cut at the "More profiles for you" or "Explore Premium profiles" marker before reasoning over the text. If that boilerplate is the entire payload, the page had not rendered and you should wait and re-read rather than conclude the profile is empty.

Harvesting long lists. Activity feeds are virtualized, so items scrolled past are removed from the DOM and a single query after scrolling to the bottom loses most of them. Collect on every scroll step into a map keyed by a stable per-item string, which recovered 83 posts on a page where the scroll-then-query approach found 63. Keep any single in-page script under about fifteen seconds of wall time, because long scroll loops are the main thing that trips the extension into disconnecting.

Post permalinks. The permalink anchor is usually absent from activity cards. Read the card's data-urn instead, which yields urn:li:activity:<id>, and build https://www.linkedin.com/feed/update/urn:li:activity:<id>/.

Contact info. Navigating straight to /in/<slug>/overlay/contact-info/ never renders the overlay and silently returns the base profile. Load the plain profile and click the control. Even then the modal renders outside <main>, so whole-page text extraction misses it and you need a screenshot or a direct shadow-piercing query.

When the inbox search finds nothing, check the Sales Navigator inbox at /sales/inbox/ before concluding there is no thread. Regular message search does not see InMail threads and will report a clean miss for a person you are actively talking to.

Writing to LinkedIn

Everything below is verified to work up to the final control. Stop there and get the user's explicit approval for that specific action before the last click.

Composing a post. The composer does not open from /feed/?shareActive=true any more; that URL now resolves to an unrelated modal. Click div[aria-label="Start a post"], noting that the label sits on an inner element while role="button" sits on its parent. The dialog is div[role="dialog"][aria-labelledby="share-to-linkedin-modal__header"]. The editor is [data-test-ql-editor-contenteditable="true"], also reachable as [role="textbox"][aria-label="Text editor for creating content"].

The editor is Quill, and the instance hangs off the editor's parent as __quill. That is by far the cleanest way to compose, because it keeps the internal model in sync and handles multi-line text without simulating hundreds of keystrokes:

const ed = __deep('[data-test-ql-editor-contenteditable="true"]')[0];
ed.parentElement.__quill.setText("line one\nline two\n");

Verified: real typing, raw DOM insertion, and the Quill API all land text and all flip the Post button from disabled to enabled, and Quill's model stayed consistent with the DOM in each case. Toolbar controls are labelled Add media, Create an event, Celebrate an occasion, More, Schedule post, Open Emoji Keyboard, and Dismiss. To abandon a draft cleanly, set the text back to "\n" first and then click Dismiss, otherwise LinkedIn keeps it as a saved draft.

Sending a message. The compose box is [role="textbox"][aria-label="Write a message…"] with a real ellipsis character, inside form.msg-form, and the send control is button.msg-form__send-button, which stays disabled until the box has content. This box is plain contenteditable rather than Quill, so set the HTML and dispatch a bubbling input event.

Enter sends the message in LinkedIn messaging. Never press Return while focus is in that box. Type by script, verify the text, then let the human click Send.

/messaging/ always redirects to the currently open thread rather than staying on the inbox URL, which is normal and not an error. Thread URLs have the shape /messaging/thread/2-<base64ish>/. Clicking a conversation row by accessibility ref is a silent no-op that reports success while nothing changes, so switch threads by navigating to the thread URL directly.

Invitations. Follow the wrong-person procedure above without shortcuts. Withdrawing is an <a> with aria-label="Withdraw invitation sent to <Full Name>". Withdrawing carries an official three-week cooldown before you can invite that person again, so it is not a free undo.

Reading state right after a click is unreliable. In one batch, 23 of 77 rows still displayed "Connect" after the invitation had genuinely been sent. Treat an ambiguous read as unknown rather than as failure, and never re-send on it. Verify in a separate later pass.

Rate limits and policy, stated honestly

This matters more than the selectors, because getting it wrong costs the user their account.

What LinkedIn actually publishes. The User Agreement effective 2025-11-03, still current in August 2026, prohibits in section 8.2 the use of "software, devices, scripts, robots" to scrape or copy the service, the use of "bots or other unauthorized automated methods" to send messages or to create, comment on, like, or share posts, the circumvention of access controls or use limits, and the copying or distribution of information obtained from the service without consent. A separate Prohibited Software and Extensions page bans third-party tools that "scrape, modify the appearance of, or automate activity on" LinkedIn, and states plainly that members using them risk having their accounts restricted or shut down. robots.txt carries a blanket prohibition on automated access without express permission.

Read that plainly: automating activity on LinkedIn violates the User Agreement. Pacing an agent to stay under a detection threshold is not a defense, since section 8.2 separately prohibits circumventing use limits. This skill therefore documents the read-and-draft posture, where the agent gathers and prepares and a human performs the visible actions, and it deliberately does not provide bulk sending machinery.

Enforcement is real and increasingly instrumented. LinkedIn's own restriction pages name three invitation triggers: sending many invitations in a short time, having many invitations ignored or marked as spam, and suspected automation. Profile views are explicitly capped daily by a velocity-based check, and LinkedIn states it will neither reveal the threshold nor lift it on request. A 2026 report found LinkedIn running a fingerprinting script that probes visitors for thousands of specific Chrome extensions, and LinkedIn confirmed on the record that it looks for extensions that scrape data and uses the result in enforcement decisions.

Numbers that are official. Maximum 30,000 first-degree connections. Free search returns at most 250 results across 25 pages, which corrects the "1,000 results" figure that most guides still repeat. Sales Navigator caps at 2,500 lead results across 100 pages. Monthly InMail credits are 5 on Premium Career, 15 on Premium Business, 50 on Sales Navigator Core, and 30 on Recruiter Lite, renewing on the billing-cycle date rather than the first of the calendar month, with credits refunded when an InMail is accepted, declined, or answered within 90 days. The commercial use limit resets at midnight PST on the first of each month and is lifted by Premium Business, Sales Navigator, and Recruiter Lite, but not by Premium Career.

Numbers that are folklore. The widely quoted ~100 invitations per week, ~20 to 25 per day, 500 pending invitation cap, and 30% acceptance-rate throttle have no primary source. They come almost entirely from automation vendors marketing their own products, which is the dominant kind of result for these queries. Treat them as rough community priors, say so when you cite them, and never present them as LinkedIn's published policy.

Failure catalogue

The full list with exact error strings is in references/failure-modes.md. The ones worth knowing before you start:

• The extension disconnects mid-run, which is the single most frequent hard block. Retry once; if the connected-browser list comes back empty, switch to the AppleScript surface.
• A batched call gets refused by the harness classifier while the identical actions pass as individual calls. Outward-facing clicks may be refused outright, which is correct and should be reported to the user rather than worked around.
• Text extraction fails with a null innerText TypeError on a bot-check interstitial titled "Just a moment...". Wait a few seconds and re-read. Never attempt the challenge.
• Profile URLs without www cause aborted navigations and timeouts. Normalize to https://www.linkedin.com/in/<slug>/ before navigating.
• The accessibility tree comes back empty on some pages while text extraction works fine, and ref-based search inherits that blindness. Fall back to in-page JavaScript.

What was verified, and when

Everything marked verified here was exercised live against a real logged-in account on 2026-08-17: the anonymous HTTP 999 authwall, the #interop-outlet shadow root, hashed class names, the mixed stacks across routes, the componentkey member URN, the single-match Topcard section, zero h1 elements, the main#workspace scroller, the composer path from trigger to an enabled Post button including the Quill instance, the messaging box and its send-button gating, the person-scoped labels across My Network and both invitation tabs, people search extraction, and Sales Navigator reachability. Draft state was cleared afterwards and nothing was published or sent.

Two paths are documented but not live-verified end to end, and are marked as such because the final click was deliberately not performed: publishing a post, and sending an invitation. The invitation click was additionally refused by the harness safety classifier during verification, which is the correct outcome.

LinkedIn ships changes constantly. When something here stops matching, re-run the Step 1 probe and trust the page over this file, then update this file. A selector that was true in August 2026 is evidence about the past, not a fact about today.