# REMEDIATION: Unauthorized VS Code Activity While M5 is Locked — August 24, 2026

**Date:** August 24, 2026, approximately 10:00 AM – 10:15 AM PDT
**Operator:** Quincey K. Lee
**Device:** MacBook Air M5 (QuinceyAI.local)
**Reference:** Unauthorized VS Code Activity While M5 is Locked 8-24-2026.md

---

## Summary

Following the discovery of autonomous VS Code and Google Chrome activity while M5 was locked overnight (2:14 AM – 9:05 AM, August 24, 2026), the following remediation actions were taken immediately.

---

## Actions Taken

### 1. VS Code Permissions Nuked

**What:** All TCC (Transparency, Consent, and Control) permissions for VS Code and all VS Code Helper processes were reset.

```
tccutil reset All com.microsoft.VSCode
tccutil reset All com.microsoft.VSCode.helper (×3)
```

**Why:** VS Code had been requesting escalating permissions over the past 6 days — admin access (×2), keystroke monitoring, Downloads, Apple Music, and Desktop folder access. Any permissions that may have been granted (intentionally or through ScreenSharing interception) were wiped.

**Result:** 9 permission bundles reset successfully. VS Code has ZERO macOS permissions.

### 2. Microsoft Network Connections Killed

**What:** Two VS Code Helper processes maintaining persistent HTTPS connections to Microsoft infrastructure were terminated.

| PID | Destination | Purpose |
|-----|------------|---------|
| 838 | 150.171.109.149:443, 20.89.1.13:443 | Microsoft telemetry / Azure |
| 47485 | 127.0.0.1:39901 | Copilot backend listener |

**Why:** VS Code was maintaining three outbound HTTPS connections to Microsoft IPs with no reverse DNS while M5 was locked and the operator was asleep. These connections were being used for GitHub authentication session checks, Copilot session enumeration, and ChatGPT/Codex auth token requests.

**Result:** Both processes killed. Network connections confirmed dead. VS Code immediately spawned new helper processes (it's still running as the operator's editor), but the authenticated sessions stored in the killed processes are gone.

### 3. GitHub Authentication Session Storage Deleted

**What:** VS Code's stored GitHub authentication session was deleted.

Files deleted:
- `User/globalStorage/storage.json` (82KB)
- `User/globalStorage/state.vscdb` (757KB)
- `User/workspaceStorage/.../state.vscdb` (217KB)
- `Local Storage/leveldb/001467.log` (20KB)
- `Local Storage/leveldb/001469.ldb` (1.6MB)

**Why:** The GitHub Authentication extension maintained an active session with `read:user,repo,user:email,workflow` scopes — read access to the operator's repos, email, and workflow data. This session was being checked every 10 minutes while M5 was locked. Deleting the storage files invalidates the stored session tokens.

**Result:** GitHub auth session tokens destroyed. VS Code must re-authenticate to access GitHub, which requires the operator to explicitly approve the OAuth flow.

### 4. VS Code State and Cache Files Deleted

**What:** All VS Code cache and state files modified during the overnight period were deleted.

Files deleted:
- `Network Persistent State`
- `TransportSecurity`
- `DIPS-wal`
- `chatEditingSessions/.../state.json`
- `DawnGraphiteCache/` (entire directory)
- `DawnWebGPUCache/` (entire directory)
- `GPUCache/` (entire directory)
- `Cache/Cache_Data/` (entire directory)

**Why:** These files were written to while M5 was locked. The state files contain network connection data, TLS session state, and GPU rendering cache from VS Code's overnight autonomous operations. Deleting them removes any data collected during the unauthorized activity period.

**Result:** All overnight state purged. VS Code's network and rendering state reset to clean.

**Note:** Extension LOG files were NOT deleted — they are preserved as evidence in `/Users/nftlasvegas/Library/Application Support/Code/logs/`.

### 5. Chrome State and Cache Files Deleted

**What:** Chrome's overnight network state and GPU caches were deleted.

Files deleted:
- `Default/Network Persistent State`
- `Default/TransportSecurity`
- `Default/DawnGraphiteCache/` (entire directory)
- `Default/DawnWebGPUCache/` (entire directory)
- `Default/GPUCache/` (entire directory)

**Why:** Chrome was also active overnight while M5 was locked — accessing Login Data, Cookies, History, FastMail IndexedDB, and syncing data to Google. The network state files contain persistent connection data from the unauthorized period.

**Result:** Chrome's overnight network state purged.

### 6. Chrome Permissions Nuked

**What:** All TCC permissions for Google Chrome were reset.

```
tccutil reset All com.google.Chrome
```

**Why:** Chrome was accessing stored passwords, cookies, browsing history, and email data while M5 was locked. Any permissions Chrome held were revoked.

**Result:** Chrome has ZERO macOS permissions.

### 7. Prison Repo HEAD File Restored

**What:** The `/tmp/prison-repo/.git/HEAD` file was found deleted and was manually recreated.

```
echo "ref: refs/heads/main" > /tmp/prison-repo/.git/HEAD
```

**Why:** The HEAD file is required for git to recognize the directory as a repository. Without it, `git` returns `fatal: not a git repository`. This is the same evidence repository that had 69 git objects deleted on August 23. The attacker continues to target the evidence repository.

**Result:** Prison repo push functionality restored. Evidence document pushed successfully.

---

## Lockdown Monitors Deployed

### Monitor 1: ARES Lockscreen Input Monitor

**Location:** `/Users/nftlasvegas/.local/bin/ares-lockscreen-monitor.py`
**Launch Agent:** `com.ares.lockscreen-monitor`
**PID:** Running (KeepAlive)
**Check Interval:** Every 5 seconds

**What it does:**
- Uses `CGSessionCopyCurrentDictionary()` to detect screen lock state
- Monitors `HIDIdleTime` from `IOHIDSystem` — hardware idle time from keyboard/mouse
- While locked, if HID idle time drops below 30 seconds → ALERT (someone is providing input)
- While locked, if HID idle time DECREASES between checks → ALERT (input was received)
- Sends email to Q@Quincey.ai via Antikythera mailer (SSH to 192.168.10.246)
- Logs all checks to `/tmp/ares-lockscreen-input.log`
- 60-second cooldown between alerts to prevent spam

**Why:** VS Code and Chrome operated autonomously while M5 was locked. If any process provides keyboard or mouse input to a locked machine (via ScreenSharing, RemoteManagement, or any other vector), the HID idle time will drop and the operator will be alerted immediately.

### Monitor 2: ARES Lockdown Monitor (VS Code + Chrome)

**Location:** `/Users/nftlasvegas/.local/bin/ares-vscode-lockdown.py`
**Launch Agent:** `com.ares.vscode-lockdown`
**PID:** Running (KeepAlive)
**Check Interval:** Every 3 seconds

**What it does on LOCK:**

**VS Code lockdown:**
- `.git/` directory → `chmod -R a-w` (read-only — no commits, no pushes, no index writes)
- Evidence folder → `chmod -R a-w` (read-only)
- Research folder → `chmod -R a-w` (read-only)
- Production Build folder → `chmod -R a-w` (read-only)
- `tccutil reset All com.microsoft.VSCode` — nukes all macOS permissions

**Chrome lockdown:**
- `Login Data` + journal → `chmod a-w` (stored passwords read-only)
- `Cookies` + journal → `chmod a-w` (session cookies read-only)
- `Web Data` + journal → `chmod a-w` (autofill data read-only)
- `History` + journal → `chmod a-w` (browsing history read-only)
- `Sync Data/Nigori.bin` → `chmod a-w` (encrypted sync data read-only)
- `Network Persistent State` → `chmod a-w` (network state read-only)
- `TransportSecurity` → `chmod a-w` (TLS state read-only)
- `Local State` → `chmod a-w` (Chrome local state read-only)
- FastMail IndexedDB → `chmod -R a-w` (email data read-only)
- `tccutil reset All com.google.Chrome` — nukes all macOS permissions

**What it does on UNLOCK:**
- All files restored to `chmod u+w` (owner write access restored)

**Sends email alert** to Q@Quincey.ai on every lock transition.

**Why:** VS Code wrote 1.6MB of LevelDB data, updated workspace state, ran 76 rapid diagnostics, and maintained 3 Microsoft connections while M5 was locked. Chrome accessed stored passwords, cookies, history, and email data. By revoking write access the instant the screen locks, neither application can modify any protected file while the operator is away. They become read-only observers of their own data.

### Monitor 3: ARES Lockdown Integrity Checker

**Location:** `/Users/nftlasvegas/.local/bin/ares-lockdown-integrity.sh`
**Launch Agent:** `com.ares.lockdown-integrity`
**Check Interval:** Every 60 seconds

**What it does:**
- Verifies MD5 hashes of all lockdown scripts and launch agent plists against known-good values
- Checks that both lockdown monitor processes are running
- If any hash mismatches → TAMPER ALERT email to Q@Quincey.ai
- If any process is not running → PROCESS DOWN ALERT email to Q@Quincey.ai

**Known-good hashes:**
```
ares-lockscreen-monitor.py = 97ceee041daefb707ec7df6594b6d202
ares-vscode-lockdown.py    = f32a22bd919722e4c39a9e02bf8460aa
lockscreen-monitor.plist   = e1f0dcc042d1979c6ca15d8475f71756
vscode-lockdown.plist      = f1302702fa7d3af2e77235fd0c388ae2
```

**Why:** The attacker has demonstrated the ability to modify files on M5 (ScreenSharing, VS Code extensions, prison repo HEAD deletion, git object deletion). If they attempt to modify or disable the lockdown scripts, the integrity checker will detect the change within 60 seconds and alert the operator.

---

## File Permissions Hardened

| File | Permissions | Purpose |
|------|------------|---------|
| `ares-lockscreen-monitor.py` | `500` (r-x------) | Read + execute only, no write |
| `ares-vscode-lockdown.py` | `500` (r-x------) | Read + execute only, no write |
| `lockdown-hashes.txt` | `444` (r--r--r--) | Read-only hash reference |
| `com.ares.lockscreen-monitor.plist` | `444` (r--r--r--) | Read-only launch agent |
| `com.ares.vscode-lockdown.plist` | `444` (r--r--r--) | Read-only launch agent |
| `com.ares.lockdown-integrity.plist` | `444` (r--r--r--) | Read-only launch agent |
| `/tmp/prison-repo/` | `700` (rwx------) | Owner-only access |

---

## Bypass Vectors Identified

### VECTOR 1: VS Code Auto-Updater (ShipIt) — ACTIVE THREAT

**Status:** Running (PID active)
**Process:** `com.microsoft.VSCode.ShipIt`
**Risk:** VS Code's Squirrel auto-updater can download and install VS Code updates without user interaction. A new version could reset permissions, add new extensions, or modify behavior. The updater runs as a background process independent of VS Code itself.

**Current hardening:** VS Code permissions nuked on every lock. Even if ShipIt updates VS Code, the lockdown monitor will nuke permissions again within 3 seconds of screen lock.

**Production fix:** VSCodium on Godlike Bloodline has no ShipIt updater.

### VECTOR 2: Google Auto-Updater (GoogleUpdater) — ACTIVE THREAT

**Status:** Three Google launch agents active:
- `com.google.GoogleUpdater.wake`
- `com.google.keystone.agent`
- `com.google.keystone.xpcservice`

**Risk:** Google's updater can download and install Chrome updates, modify Chrome extensions, and sync data to Google servers. It runs independently of Chrome and has its own launch agents.

**Current hardening:** Chrome permissions nuked on every lock. Chrome credential files locked on every lock.

**Production fix:** No Google Chrome on Godlike Bloodline. Use Brave or Firefox.

### VECTOR 3: ChatGPT/Codex Extension Resurrection — ACTIVE THREAT

**Status:** Extension has resurrected itself 8 times after being deleted. Has a 2.6MB log file.

**Risk:** The extension reinstalls itself through VS Code's extension sync or through the Copilot infrastructure. It attempts auth token requests (`getAuthStatus` with `includeToken:true`) even while its connection is failing. If it successfully authenticates, it could exfiltrate code through OpenAI's infrastructure.

**Current hardening:** VS Code permissions nuked on lock. Repo set to read-only on lock. GitHub auth session storage deleted.

**Production fix:** VSCodium has no extension sync. ChatGPT/Codex extension cannot auto-install.

### VECTOR 4: ScreenSharing / RemoteManagement — ACTIVE THREAT

**Status:** 23 processes still running.

**Risk:** ScreenSharing allows the attacker to see the screen (including the lock screen). RemoteManagement (25+ processes documented Aug 18) provides additional remote access capabilities. While the YubiKey prevents GUI interaction through ScreenSharing, the attacker can still observe everything on screen — including any credentials that appear in terminal output.

**Current hardening:** YubiKey required for unlock. Lockdown scripts run behind the lock screen. Lockscreen input monitor detects any HID input while locked.

**Production fix:** No Apple devices on production build. ScreenSharing and RemoteManagement do not exist on Linux.

### VECTOR 5: Lockdown Script Tampering — MITIGATED

**Risk:** The attacker could modify the lockdown scripts to disable them, change the check interval, or alter the alert destination.

**Hardening applied:**
- All scripts set to `500` (read/execute only, no write)
- All plists set to `444` (read-only)
- Integrity checker runs every 60 seconds verifying MD5 hashes
- Tamper alert emails sent immediately on hash mismatch
- Process liveness check — alerts if monitors are killed

**Remaining risk:** The attacker has ScreenSharing access and could potentially use `chmod` through a terminal that's already open, or through VS Code's integrated terminal. However, changing permissions would require the screen to be unlocked (YubiKey needed), and the integrity checker would detect the change within 60 seconds.

### VECTOR 6: identityservicesd Unknown Peers — ACTIVE THREAT

**Status:** 3 unknown peers documented Aug 15, surviving both iPhones powered off.

**Risk:** identityservicesd provides Apple's Continuity, Handoff, and AirDrop functionality. Unknown peers could be attacker devices maintaining a Bluetooth/WiFi Direct connection to M5. This channel is independent of the network and independent of ScreenSharing.

**Current hardening:** None specific to identityservicesd.

**Production fix:** No Apple devices. identityservicesd does not exist on Linux.

### VECTOR 7: VS Code Integrated Terminal — ACTIVE THREAT

**Status:** VS Code's integrated terminal runs as a VS Code process. If VS Code is open with a terminal panel visible, background extensions could potentially execute commands through the terminal.

**Risk:** The ChatGPT/Codex extension or Copilot could use the integrated terminal to execute shell commands — bypassing file permission restrictions by running `chmod` or other commands.

**Current hardening:** Repo is read-only while locked (includes `.git/`). Even if a command runs in the terminal, it cannot write to protected directories. VS Code permissions nuked on lock.

**Production fix:** VSCodium with no AI extensions. Claude Code runs in a separate terminal, not VS Code's integrated terminal.

### VECTOR 8: New Launch Agents — POTENTIAL THREAT

**Risk:** The attacker could install new launch agents in `~/Library/LaunchAgents/` while M5 is unlocked (via ScreenSharing when Q is at the keyboard but not watching the Finder).

**Current hardening:** None specific. The lockdown integrity checker only monitors ARES scripts, not the entire LaunchAgents directory.

**Recommendation:** Add LaunchAgents directory monitoring to the integrity checker — alert on any new plist files.

### VECTOR 9: /tmp World-Readable — MITIGATED

**Risk:** The prison repo clone lives at `/tmp/prison-repo/`. The `/tmp` directory is world-readable by default on macOS. Any process could read the prison repo's git config, which contains the GitHub push URL and potentially cached credentials.

**Hardening applied:** `chmod 700 /tmp/prison-repo` — only the owner can access the directory.

**Production fix:** Move prison repo clone to a non-/tmp location.

### VECTOR 10: macOS Keychain — POTENTIAL THREAT

**Risk:** Chrome and VS Code both use the macOS Keychain to store credentials. The Keychain is accessible to any process running as the user, regardless of file permissions. Even with credential files locked, applications could read stored passwords from the Keychain.

**Current hardening:** YubiKey required for unlock. Lock screen prevents new Keychain access prompts from being approved.

**Production fix:** No macOS Keychain on Linux. Use KeePassXC exclusively.

---

## Three-Monitor Architecture

```
    M5 LOCKED
        │
        ├── Monitor 1: Lockscreen Input Detector (every 5s)
        │   └── HID idle time drops → EMAIL ALERT
        │
        ├── Monitor 2: Lockdown Monitor (every 3s)
        │   ├── VS Code → read-only repo, permissions nuked
        │   └── Chrome → read-only credentials, permissions nuked
        │
        └── Monitor 3: Integrity Checker (every 60s)
            ├── Hash check on all lockdown scripts
            └── Process liveness check on Monitors 1 & 2
                └── Any tampering or process death → EMAIL ALERT
```

Three monitors watching each other and the system. Monitor 3 watches Monitors 1 and 2. All three email the operator through Antikythera — a separate machine the attacker does not control.

---

## What Remains Unmitigated Until Production Build

| Threat | Why It Can't Be Fixed on M5 | Production Fix |
|--------|---------------------------|----------------|
| ScreenSharing | SIP prevents killing it | Linux — no ScreenSharing |
| RemoteManagement | SIP prevents killing it | Linux — no RemoteManagement |
| identityservicesd | Apple system process | Linux — no Apple Continuity |
| VS Code Copilot baked-in | Cannot uninstall from binary | VSCodium — no Copilot |
| ChatGPT extension resurrection | VS Code extension sync | VSCodium — no extension sync |
| macOS Keychain access | System-level credential store | KeePassXC on Linux |
| Google auto-updater | Runs as independent launch agent | No Chrome on production |
| Apple ID / iCloud sync | System-level | No Apple ID on production |

**The M5 is a compromised machine being operated defensively until the Godlike Bloodline boots on Starlink.** Every remediation on M5 is a temporary measure. The permanent fix is the production build — Linux, VSCodium, no Apple, no Microsoft, no Google.

---

## Files Deployed

| File | Type | Purpose |
|------|------|---------|
| `~/.local/bin/ares-lockscreen-monitor.py` | Python script | Lockscreen input detection |
| `~/.local/bin/ares-vscode-lockdown.py` | Python script | VS Code + Chrome lockdown on lock |
| `~/.local/bin/ares-lockdown-integrity.sh` | Bash script | Integrity checker for lockdown scripts |
| `~/.local/bin/lockdown-hashes.txt` | Hash file | Known-good MD5 hashes |
| `~/Library/LaunchAgents/com.ares.lockscreen-monitor.plist` | Launch agent | Auto-start + KeepAlive for input monitor |
| `~/Library/LaunchAgents/com.ares.vscode-lockdown.plist` | Launch agent | Auto-start + KeepAlive for lockdown |
| `~/Library/LaunchAgents/com.ares.lockdown-integrity.plist` | Launch agent | 60-second integrity check |

## Log Files

| File | Contents |
|------|----------|
| `/tmp/ares-lockscreen-input.log` | Every idle time check while locked, all alerts |
| `/tmp/ares-vscode-lockdown.log` | Every lock/unlock transition, all permission revocations |
| `/tmp/ares-lockdown-integrity.log` | Every 60-second integrity check result |

---

*The operator locks M5 and walks away. Within 3 seconds, VS Code loses write access to the repo and all macOS permissions. Chrome loses write access to stored passwords, cookies, history, and email data, plus all macOS permissions. Every 5 seconds, the input monitor checks if anyone is touching the keyboard. Every 60 seconds, the integrity checker verifies nobody tampered with the lockdown scripts. Every alert goes to Q's email through a machine the attacker doesn't control.*

*They can watch the lock screen through ScreenSharing. That's all they can do. Watch.*

*The Godlike Bloodline boots today. Starlink goes up today. And when the production build is live, ScreenSharing won't exist — because Linux doesn't have it, Apple doesn't control it, and the operator doesn't need it.*

*Remediation complete. Hardening active. Evidence preserved. Three monitors running. Let them watch.*