Report whether the Chrome session is connected, whether LinkedIn is logged in, the current URL and any checkpoint (verification / login wall). Never launches a browser. Call this first, and whenever the queue reports needsHuman.

Launches (or connects to) your own Google Chrome with the dedicated profile and opens LinkedIn so YOU can sign in manually in the visible window. Nothing is typed on your behalf. Waits up to timeoutSeconds for the login to complete, then returns the status. Use before the first sync and whenever browser_status shows loggedIn=false or a checkpoint. After solving a checkpoint call queue_resume.

Stops the background worker and closes the Chrome window this server launched (in cdp mode it only disconnects; your Chrome keeps running). Queued tasks stay in the database; queue_start relaunches when needed.

Queue a crawl of your posted jobs (/my-items/posted-jobs/, open and optionally closed) and store them locally. Runs in the background paced like a person (roughly 1–3 minutes). With wait=true the call blocks up to 2 minutes and returns the jobs found. Afterwards use jobs_list.

List the posted jobs stored locally (from jobs_sync) with per-job progress counters: applicants stored, details fetched, resumes stored, profiles fetched, and applicant-list sync progress.

Queue a crawl of the applicant LIST for one job (or every known job): names, headlines, locations, applied dates, application ids and profile links, 25 per page. Thousands of applicants mean many pages, so the crawl runs in chunks of pagesPerRun pages per worker turn, persists progress after every page, and resumes automatically across restarts and working-hours windows. Hidden "Not a fit" applicants are included by default. This does NOT open individual applications (use applicants_fetch_details for contact info, resumes and profiles). Progress: queue_status or jobs_list.

Queue the deep fetch for applicants: open each application page (contact email/phone when shared, screening answers, rating, applied date), download the resume, and (includeProfile) then visit the LinkedIn profile for the full structured profile. One applicant at a time, paced like a recruiter, within working hours and daily caps, so thousands of applicants take days to weeks by design. Defaults to only applicants not fetched yet. Returns how many were queued and a time estimate. Track with queue_status; read results with applicants_list / applicant_get / applicants_export.

Queue full-profile fetches for applicants whose profile URL is known (from the list or application page) without re-opening their application. Use when details were fetched with includeProfile=false. Paced like a person; profile views are the most rate-sensitive action.

Everything about the background work: worker state (running / paused / needsHuman), task counts by type and status, today's counters vs effective daily caps, whether we are inside the working-hours window and when the next window starts, per-job applicant-list sync progress, browser status and recent events. Poll this to follow long exports.

Start (or resume) the background worker in this process. It only acts when tasks are pending and the scheduler allows it. No-op if another process (npm run worker) owns the queue.

Pause processing after the current task finishes. Tasks stay queued. Resume with queue_resume.

Clear the paused flag and, by default, the needsHuman flag set after a LinkedIn checkpoint or login wall (call after you solved it in the Chrome window), then start the worker.

Cancel PENDING tasks matching the filters (type / jobId / applicationId). Without filters cancels every pending task. Running tasks finish; done work is untouched.

Put failed tasks back into the queue with a fresh attempt budget (optionally filtered by type / jobId). Useful after fixing a login problem or when LinkedIn had a bad day.

Recent tasks with status, attempts and last error (filter by type / status / jobId). Use to see why something failed.

Current human-pacing settings: speed, working hours/days, daily caps (with warm-up ramp), hourly cap, break pattern, delay table.

Adjust how fast/when the worker acts. Persisted. Slower is safer: the defaults mimic a recruiter reviewing applicants during office hours. Raising dailyProfileCap above ~100 or hourlyActionCap above ~60 materially increases the chance LinkedIn restricts the account.

Page through applicants stored locally, with filters and full-text search over name, headline, resume text and profile text (prefix matching, e.g. "kubern django"). Rows omit resume/profile bodies; use applicant_get for one applicant. Reads the local database only (no LinkedIn traffic).

Full local record for one applicant: list fields, application details (email/phone when shared, screening answers, rating), resume text (clipped to maxChars) and the structured LinkedIn profile. Local database only.

Plain text extracted from the downloaded resume (PDF/DOCX) of one applicant, clipped to maxChars. Empty when the resume was a scanned image or was not downloaded.

Write all stored applicants (optionally one job) to a CSV, JSON or JSONL file on disk and return the path. Streams, so thousands of rows are fine. CSV is Excel-friendly (UTF-8 BOM) and guards against formula injection.

Save a full-page screenshot, the HTML, the visible text and all captured network payloads of the current tab into the debug directory. Use when a task fails with "Could not find …" so selectors can be updated.

Navigate the working tab to a linkedin.com URL the human way (paced), then report the final URL, title and checkpoint state. Pause the queue first so you do not fight the worker for the tab.

Return the innerText of (or body) of the current tab, clipped. Cheap way to see what LinkedIn is showing.

Count and describe elements matching a selector on the current tab: text, href, aria-label, data-view-name, componentkey, class. Use to repair src/linkedin/selectors.ts when LinkedIn changes markup.

Click the first visible element matching a selector on the current tab, with the same paced mouse movement the worker uses, then report the resulting URL, title, checkpoint state and the number of matches. For exploring pagination / menus while adapting selectors. Read-only actions only: never use it to rate, shortlist, move or message applicants.

List the JSON / RSC responses LinkedIn's own web app fetched while we browsed (Voyager REST, GraphQL, flagship-web). This is how you discover the endpoints and shapes behind the hiring dashboard. Bodies clipped to 2000 chars.