›_ Claude Code Issues
Claude Code Issues / #79004

[BUG]

Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 0 comments · opened Jul 19, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Across a multi-day Claude Code session using the claude-in-chrome MCP extension, linkedin.com/jobs/view/{id} pages progressively stopped returning their job description content via get_page_text, while page metadata (title, company, comp badge, location, remote/full-time tags, applicant count) continued to load normally. Two distinct failure modes were observed, described separately below. The issue persisted across a session that spanned three calendar days (2026-07-16 through 2026-07-18) and multiple fresh tab groups, ruling out a simple per-tab or per-minute cause.

What Should Happen?

Failure Mode 2 — JD body ("About the job") never renders, page metadata loads fine

Symptom: get_page_text on a freshly navigated, single (non-parallel) tab returns the page's structural chrome correctly — job title, company name, company rating, location, comp range badge (when present), Remote/Full-time/Contract tags, "posted X ago," applicant count, and the full LinkedIn nav/footer/language-list boilerplate — but the actual job description body (the section that would appear under "About the job") is entirely absent. Retrying with waits up to 8 seconds, page scrolls, and full page reloads (navigate() to the identical URL again) did not resolve it for the affected URLs.

Not resolved by:

  • Waiting longer (tested up to 8s single waits, and repeated wait+check cycles)
  • Scrolling the page (tested computer scroll action, 5 ticks down)
  • Full page reload via re-navigate() to the same URL
  • Opening a completely fresh tab group (tested via tabs_close_mcp + tabs_context_mcp createIfEmpty)
  • Waiting across a multi-hour gap within the same day
  • Waiting across a calendar-day boundary (tested twice: 2026-07-16→17 and 2026-07-17→18)

Affected URLs observed (JD body never loaded, 2+ attempts each):

┌───────────────────────────────────┬──────────────────────────────────┬─────────────┬────────────────────────┐
│ URL │ Job title / Company │ First │ Status │
│ │ │ attempted │ │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────────┤
│ linkedin.com/jobs/view/4440687399 │ Issues & Program Manager, │ 2026-07-16 │ Never loaded │
│ │ Product Operations / Jobgether │ │ │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────────┤
│ │ Release Train Manager / Sand │ │ Never loaded (retried │
│ linkedin.com/jobs/view/4441240589 │ Cherry │ 2026-07-16 │ 2026-07-17, still │
│ │ │ │ failed) │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────────┤
│ │ Manager, Delivery Manager / │ │ Never loaded (retried │
│ linkedin.com/jobs/view/4441905015 │ Deloitte │ 2026-07-16 │ 2026-07-17, still │
│ │ │ │ failed) │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────────┤
│ linkedin.com/jobs/view/4440770109 │ Client Delivery Project Manager │ 2026-07-16 │ Never loaded │
│ │ (Commercialization) / Velera │ │ │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────────┤
│ │ Program Manager, Software │ │ Never loaded (retried │
│ linkedin.com/jobs/view/4423006612 │ Delivery / Walker & Dunlop │ 2026-07-17 │ 2026-07-18, still │
│ │ │ │ failed) │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────────┤
│ linkedin.com/jobs/view/4437880841 │ Card Program Operations & │ 2026-07-18 │ Never loaded │
│ │ Implementation Manager / FV Bank │ │ │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────────┤
│ linkedin.com/jobs/view/4439265646 │ Implementation Manager / Trusaic │ 2026-07-18 │ Never loaded │
└───────────────────────────────────┴──────────────────────────────────┴─────────────┴────────────────────────┘

Not affected (JD body loaded successfully, same session, interspersed with the above):

  • linkedin.com/jobs/view/4418061573 (Broccoli AI) — 2026-07-15
  • linkedin.com/jobs/view/4439879897 (Intellibus) — 2026-07-15
  • linkedin.com/jobs/view/4441228162 (VBeyond) — 2026-07-15
  • linkedin.com/jobs/view/4438701140 (Niche SSP) — 2026-07-16, loaded after 2 retries
  • linkedin.com/jobs/view/4441452769 (Drips) — 2026-07-16, loaded after reload + retries
  • Not every load after the pattern began failed — success became intermittent rather than binary, then trended toward consistent failure for all-new URLs by 2026-07-17/18.

Approximate volume at onset: Failures began appearing after roughly 20-25 cumulative linkedin.com/jobs/view/ page loads within the session (spanning both Failure Mode 1's parallel-tab batch and prior sequential loads). By ~30-40 cumulative loads (spanning into 2026-07-18), success rate for new URLs was effectively 0%.

Error Messages/Logs

Failure Mode 1 — Stale tab content after navigate() reports success

Symptom: Calling navigate(url, tabId) on a tab returns a success response showing the new URL, and the immediately-following tab-context listing shows the tab's title/URL updated correctly. However, the next get_page_text(tabId) call on that same tab returns the content of a previous page that had been loaded in that tab earlier in the session — not the newly navigated URL.

Trigger condition: Occurred specifically when multiple tabs (5+) were opened in parallel via repeated tabs_create_mcp calls, then each navigated to a different URL in separate tool calls within the same or adjacent turns. Chrome's background tab discarding (memory saver) appears to be the proximate cause — tabs_context_mcp at the time showed affected tabs with URLs like:
chrome-extension://laameccjpleogmfhilmffpdbiibgbekf/suspended.html?title=<old-title>&url=<old-url>&time=<timestamp>
i.e., the extension's own suspended-tab placeholder page, referencing the old URL, not the newly navigated one. A subsequent navigate() call to the same tabId would appear to succeed (tab context showed the new URL as the tab title) but get_page_text still returned stale content.

Reliable workaround found: Closing the tab (tabs_close_mcp) — which auto-removes the tab group when it was the last tab — and creating a fresh tab group (tabs_context_mcp with createIfEmpty: true) followed by a single navigate() + get_page_text() on the new tab reliably resolved this. Reusing an existing/previously-suspended tabId did not.

Reproduction:
1. Open 5 tabs via 5x tabs_create_mcp.
2. Navigate each of the 5 tabs to a distinct linkedin.com/jobs/view/{id} URL in one message (5 parallel navigate calls).
3. Wait, then call get_page_text on all 5 tabs.
4. Observe: some/all tabs return content matching a URL from earlier in the session, not the URL just navigated to.

---
Failure Mode 2 — JD body ("About the job") never renders, page metadata loads fine

Symptom: get_page_text on a freshly navigated, single (non-parallel) tab returns the page's structural chrome correctly — job title, company name, company rating, location, comp range badge (when present), Remote/Full-time/Contract tags, "posted X ago," applicant count, and the full LinkedIn nav/footer/language-list boilerplate — but the actual job description body (the section that would appear under "About the job") is entirely absent. Retrying with waits up to 8 seconds, page scrolls, and full page reloads (navigate() to the identical URL again) did not resolve it for the affected URLs.

Steps to Reproduce

Bug Report: claude-in-chrome — LinkedIn job pages stop loading JD content after volume

Summary

Across a multi-day Claude Code session using the claude-in-chrome MCP extension, linkedin.com/jobs/view/{id} pages progressively stopped returning their job description content via get_page_text, while page metadata (title, company, comp badge, location, remote/full-time tags, applicant count) continued to load normally. Two distinct failure modes were observed, described separately below. The issue persisted across a session that spanned three calendar days (2026-07-16 through 2026-07-18) and multiple fresh tab groups, ruling out a simple per-tab or per-minute cause.

Environment

  • Tool: claude-in-chrome MCP extension (tools used: navigate, get_page_text, computer [wait/scroll/screenshot], tabs_create_mcp, tabs_close_mcp, tabs_context_mcp)
  • Platform: Windows 11 Pro, PowerShell/Git Bash primary shells
  • Target site: linkedin.com (public job-view pages, not logged-in-only content)
  • Session length: single extended Claude Code conversation spanning 2026-07-15 through 2026-07-18, with ~30-40 total linkedin.com/jobs/view/ navigations across evaluation work

---
Failure Mode 1 — Stale tab content after navigate() reports success

Symptom: Calling navigate(url, tabId) on a tab returns a success response showing the new URL, and the immediately-following tab-context listing shows the tab's title/URL updated correctly. However, the next get_page_text(tabId) call on that same tab returns the content of a previous page that had been loaded in that tab earlier in the session — not the newly navigated URL.

Trigger condition: Occurred specifically when multiple tabs (5+) were opened in parallel via repeated tabs_create_mcp calls, then each navigated to a different URL in separate tool calls within the same or adjacent turns. Chrome's background tab discarding (memory saver) appears to be the proximate cause — tabs_context_mcp at the time showed affected tabs with URLs like:
chrome-extension://laameccjpleogmfhilmffpdbiibgbekf/suspended.html?title=<old-title>&url=<old-url>&time=<timestamp>
i.e., the extension's own suspended-tab placeholder page, referencing the old URL, not the newly navigated one. A subsequent navigate() call to the same tabId would appear to succeed (tab context showed the new URL as the tab title) but get_page_text still returned stale content.

Reliable workaround found: Closing the tab (tabs_close_mcp) — which auto-removes the tab group when it was the last tab — and creating a fresh tab group (tabs_context_mcp with createIfEmpty: true) followed by a single navigate() + get_page_text() on the new tab reliably resolved this. Reusing an existing/previously-suspended tabId did not.

Reproduction:

  1. Open 5 tabs via 5x tabs_create_mcp.
  2. Navigate each of the 5 tabs to a distinct linkedin.com/jobs/view/{id} URL in one message (5 parallel navigate calls).
  3. Wait, then call get_page_text on all 5 tabs.
  4. Observe: some/all tabs return content m the session, not the URL just navigated to.

---
Failure Mode 2 — JD body ("About the job") never renders, page metadata loads fine

Symptom: get_page_text on a freshly navigated, single (non-parallel) tab returns the page's structural chrome correctly — job title, company name, compage badge (when present),Remote/Full-time/Contract tags, "posted X ago," applicant count, and the full LinkedIn nav/footer/language-list boilerplate — but the actual job descriptild appear under "About the job") is entirely absent. Retrying with waits up to 8 seconds, page scrolls, and full page reloads (navigate() to the identical URL again) did not resolve it for the affected
Not resolved by:

  • Waiting longer (tested up to 8s single waits, and repeated wait+check cycles) - Scrolling the page (tested computer scro
  • Full page reload via re-navigate() to the same URL - Opening a completely fresh tab group (tes_context_mcp createIfEmpty)
  • Waiting across a multi-hour gap within the same day - Waiting across a calendar-day boundary (nd 2026-07-17→18)

Affected URLs observed (JD body never load
┌───────────────────────────────────┬─────┬─────────────┬────────────────────────┐
│ URL │ Job title / Company │ First │ Status │ │ │ attempted │ │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────│ linkedin.com/jobs/view/4440687399 │ Issu│ 2026-07-16 │ Never loaded │
│ │ Product Operations / Jobgether │ │ ├───────────────────────────────────┼─────┼─────────────┼────────────────────────┤
│ │ Release Train Manager / Sand │ │ Never loaded (retri│ linkedin.com/jobs/view/4441240589 │ Cher│ 2026-07-16 │ 2026-07-17, still │
│ │ │ │ failed) ├───────────────────────────────────┼─────┼─────────────┼────────────────────────┤
│ │ Manager, Delivery Manager / │ │ Never loaded (retri│ linkedin.com/jobs/view/4441905015 │ Delo│ 2026-07-16 │ 2026-07-17, still │
│ │ │ │ failed) ├───────────────────────────────────┼─────┼─────────────┼────────────────────────┤
│ linkedin.com/jobs/view/4440770109 │ Client Delivery Project Manager │ 2026-07-16 │ Never loaded │ │ (Com│ │ │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────│ │ Prog│ │ Never loaded (retried │
│ linkedin.com/jobs/view/4423006612 │ Delivery / Walker & Dunlop │ 2026-07-17 │ 2026-07-18, still │ │ │ │ failed) │
├───────────────────────────────────┼──────────────────────────────────┼─────────────┼────────────────────│ linkedin.com/jobs/view/4437880841 │ Card│ 2026-07-18 │ Never loaded │
│ │ Implementation Manager / FV Bank │ │ ├───────────────────────────────────┼─────┼─────────────┼────────────────────────┤
│ linkedin.com/jobs/view/4439265646 │ Implementation Manager / Trusaic │ 2026-07-18 │ Never loaded └───────────────────────────────────┴─────┴─────────────┴────────────────────────┘
Not affected (JD body loaded successfully,ith the above):

  • linkedin.com/jobs/view/4418061573 (Broccoli AI) — 2026-07-15 - linkedin.com/jobs/view/4439879897 (Intel
  • linkedin.com/jobs/view/4441228162 (VBeyond) — 2026-07-15 - linkedin.com/jobs/view/4438701140 (Nicheter 2 retries
  • linkedin.com/jobs/view/4441452769 (Drips) — 2026-07-16, loaded after reload + retries - Not every load after the pattern began fittent rather than binary, then trendedtoward consistent failure for all-new URLs by 2026-07-17/18.

Approximate volume at onset: Failures began appearing after roughly 20-25 cumulative linkedin.com/jobs/vieloads within the session (spanning both Faatch and prior sequential loads). By ~30-40cumulative loads (spanning into 2026-07-18), success rate for new URLs was effectively 0%.
--- Working hypothesis (unconfirmed)
LinkedIn's job pages render structural/metthe initial HTML payload, then lazy-load the actual job description body via a follow-up client-side request (visible as a skeleton-loader placeholder content arrives). The pattern — metadata aively absent, onset correlated withcumulative request volume rather than time elapsed, and persistence across day boundaries — is consistent requesting session/fingerprint being flaggn and having that specific lazy-loadedpayload silently withheld, rather than an outright block (no CAPTCHA, no error page, no HTTP error observea permanently empty content slot). This isn LinkedIn's documented anti-scrapingapproach (browser fingerprinting + rate-limit monitoring, described publicly as producing "quiet throttlinthan hard blocks after a request-volume then confirmed against any LinkedIn-sidesignal — no error was surfaced to the tool, and there's no way from the client side to distinguish "Linkedwithheld it" from "the extension's contentegitimately slow-loading element" withoutdeeper instrumentation (e.g., network request inspection during the failure).
What would help confirm root cause

  • Network request logs (read_network_requests if available/instrumented) during a reproduction, to see wheclient actually issues the lazy-load XHR/f response (status code, payload) comes back, versus the request never firing at all. - A parallel test against a fresh browser his session's LinkedIn-authenticated cookie, to isolate session-fingerprint throttling from a general extension/content-script bug. - Confirmation of whether read_page (accesent in the DOM that get_page_text simplyisn't extracting, versus the element genuinely never appearing in the DOM at all.

Impact
Each failed attempt is a full tool round-trip; get_page_text returns ~150-200 tokens of repeated LinkedIn nav/footer/language-selector boilerplate ores. Prior to identifying this pattern, theagent retried 4-6x per stuck URL before giving up, which is now capped at 2 attempts (documented as a standing rin this project's modes/_custom.md under R underlying tool/extension behavior itselfis what needs investigation, since the workaround only reduces token waste, it doesn't fix the actual data-loss problem (7+ job postings this session were user manually pasting JD text).

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.17.0

Claude Code Version

1.18.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: MCP server connection issues, IDE & terminal integration

Browse all Claude Code issue topics →