🛠️ Debugging Report: LinkedIn Auto Job Applier
📌 Project Overview
This project is an AI-based automation tool that searches and applies for relevant jobs on LinkedIn using Selenium and Chrome automation. The tool handles job discovery, Easy Apply workflows, resume usage, and application submission automatically.
During local setup, the project worked on other systems but failed on mine. This report documents the issue, investigation, root cause, fix, and final outcome.
❗ Problem Statement
When running the project locally:
- Chrome browser opened successfully
- LinkedIn did not open
- No runtime errors were thrown
- Automation never proceeded
This created confusion because the same codebase worked correctly on other machines.
🔍 Root Cause Analysis
After systematic debugging, the main causes were identified:
1️⃣ Chrome User Profile Conflict (Primary Issue)
- The script attempted to reuse the default Chrome profile
- On my system, this profile was already:
- In use by another Chrome session, or
- Locked/corrupted for Selenium access
- Result:
- Chrome opened
- Selenium lost control
- LinkedIn never loaded
2️⃣ Stealth Mode Was Not the Real Problem
stealth_mode was correctly imported and configured
- The failure occurred before any LinkedIn navigation
- The issue was browser-session related, not bot detection
3️⃣ No Explicit Navigation for Debugging
- Initially, there was no forced navigation using
driver.get()
- This made it unclear whether Selenium had control of the browser
4️⃣ tempCodeRunnerFile.py Confusion (Non-Issue)
- VS Code automatically created
tempCodeRunnerFile.py
- It was:
- Untracked
- Not part of execution
- This file had no impact on the project
🧪 Debugging Steps Performed
✅ Step 1: Manual Navigation Test
A temporary debug check was added right after driver creation:
driver.get("https://www.linkedin.com")
input("LinkedIn opened? Press ENTER")
Result: LinkedIn did not open → confirmed browser-session issue
✅ Step 2: Force a Clean Selenium Profile (Key Fix)
📍 File: modules/open_chrome.py
❌ Original Code
if safe_mode:
print_lg("SAFE MODE: Will login with a guest profile")
else:
profile_dir = find_default_profile_directory()
if profile_dir:
options.add_argument(f"--user-data-dir={profile_dir}")
✅ Debug Fix Applied
# FORCE CLEAN TEMP PROFILE (DEBUG FIX)
options.add_argument("--user-data-dir=C:\\temp\\selenium-profile")
Why this worked:
- Avoided conflicts with existing Chrome sessions
- Gave Selenium full control over the browser
- Ensured a clean and stable environment
✅ Step 3: Login Persistence Verification
- First run:
- LinkedIn opened
- Manual login performed
- Second run:
- Auto-login succeeded
- Redirected to LinkedIn feed
✔ Confirmed session persistence
✅ Step 4: Resume Automation
- Removed debug pauses
- Allowed the agent to continue
- Job search and Easy Apply automation worked correctly
⚠️ LinkedIn Rate-Limit Behavior
Observed Message
"You’re applying too fast. Please try again later."
Explanation
- This is expected LinkedIn behavior
- Happens to both bots and humans
- Triggered by:
- High-frequency applications
- Repetitive patterns
🧠 Recommendations
- Limit daily applications
- Add random delays between actions
- Pause automation when rate-limit messages appear
- Resume after a cooldown period
🚫 This is not a bug, but a platform protection mechanism
✅ Final Outcome
- Chrome + Selenium issue resolved
- LinkedIn opens reliably
- Login session persists
- Job applications run automatically
- Rate-limit behavior understood and managed
📌 Key Takeaway
Most Selenium automation failures are caused by browser profile conflicts, not code errors. Using a clean, dedicated Selenium profile is critical for stable automation.
⭐ If you found this report helpful, feel free to star the repository or contribute improvements!