Delete X data again: posts, reposts, likes, bookmarks, and tombstones

[micahflee]

Closes #711.

X rotates the identifiers its delete mutations are addressed by, and moved the timelines the mutations claim to come from. The four identifiers were hardcoded in four places, each written twice, and every referrer Cyd sent pointed at a route that now redirects.

What changed

One resolver, keyed by operation name, answers where a mutation goes, what identifier it carries, and what referrer it sends. Seeded from the #709 capture:

Operation	Identifier	Referrer
DeleteTweet	nxpZCY2K-I6QoFHAHeojFQ (rotated)	https://x.com/<username>
DeleteRetweet	ZyZigVsNiFO6v1dEks1eWg (new)	https://x.com/<username>/reposts
UnfavoriteTweet	ZYKSe-w7KEslx3JhSIk5LA	https://x.com/i/history/likes
DeleteBookmark	Wlmlj2-xzyS1GN3a6cj-mQ	https://x.com/i/history

It prefers an identifier observed in this session's own traffic over the seed. The store lives on the X controller, fed by the webRequest hook that already watches for rate limits: in memory for the session, no persistence, no invalidation. A cold-start run relies on the seeds.

Undoing a repost is its own operation. X sends DeleteRetweet naming the post that was reposted, not the repost, so reposts now carry that post's ID from the reposts timeline into the database (retweetedTweetID) and out again through the delete list.

Routes match referrers. Posts are deleted from the profile page and reposts from /reposts. Likes and bookmarks accept the redirect into X's /i/ namespace rather than dying on it — without that, neither job sent a single mutation.

Unfollowing now takes accounts in order. It reaches the Following button by [data-testid$="-unfollow"], but it walked an index across the matches — and X flips that attribute to -follow once an account is unfollowed while leaving the row in the list, so every unfollow shifted the remaining matches up by one. It unfollowed the first account, then the third, then the fifth, and died on MouseoverFailed when the index ran past what was left. It now always takes the first remaining match and re-counts.

The tombstone works, and is no longer behind x_tombstone. All three jobs did something wrong, and each was wrong in its own way:

• The banner never reached the page. The script fetched the banner's data: URL to make a Blob, but X's CSP has no data: in connect-src, so the page refused it and reported only "Failed to fetch". It decodes the base64 itself now.
• Locking the account threw. It read .checked off the first checkbox the moment the page loaded, before X had rendered any, so the script died on undefined and Electron reported "Script failed to execute". It waits for the checkbox.
• The bio was typed in with sendInputEvent, a key at a time. keyDown and keyUp move focus and press Backspace — which is why the tabbing and deleting looked like they worked — but they insert no text without a char event. The textarea kept whatever X had put there and the save wrote it straight back. It goes through React's own value setter now, which took the tab loop, the per-character typing and the keycode table with it.

Both saves are checked. The banner and bio jobs clicked Save and called it done; a click on a button that does nothing still looks like a click. They read the profile back now — the banner URL either side of the save, the textarea after a reload — and a save that changed nothing is a reported failure rather than a finished job.

Finding that out

scripts/x-capture/probe-profile.ts is new. After two wrong guesses about why the profile dialog ignored Cyd, it drives a real Chromium through every plausible way of making the change and records the Save button state, the calls that carry the change, and whether the value survived a reload. Two rounds settled it:

• Every banner delivery works, Cyd's own included, and real key events set the bio. So neither the file nor the typing was at fault.
• Cyd's element.click(), its 250ms Apply-to-Save gap, and its tab-to-the-textarea all work too — the tab loop lands on TEXTAREA[name=description] after nine presses.
• X's profile Save button is never disabled, which killed an assumption an earlier commit here had rested on.

That left the Electron webview as the only difference, and the missing char event as the cause.

It also confirmed the file input that used to be a guess: the dialog carries three fileInput elements and the banner is the first.

Also

Spacing on the delete review page — 5 tweetsthat are older than 2 days — was Vue's condense deleting a whitespace-only text node between two elements. The dashboard cards lost 72px of height so two rows clear the default 1000x900 window without a scrollbar, which matters more now that the tombstone card makes four. The lock-account checkbox had no wizard.lockAccountLabel string and rendered the key.

Known limitations, accepted

• The learn-from-traffic preference never fires for these four operations. X's own client issues them only when a person clicks delete, which does not happen during automation. A rotation is still fixed by recapturing and reseeding off an error report. The read operations do get learned.
• Existing databases take the fallback. Every repost already saved has retweetedTweetID null and is deleted the way Cyd has always deleted one, until a save run backfills it.

Testing

Resolver tested directly, both directions. Delete flows driven through the existing job seam with browser primitives stubbed, asserting the routes visited, the selectors awaited, and the mutation each job sends. The tombstone tests run the generated scripts against a stubbed page, with fetch throwing the way X's CSP makes it throw.

Renderer suite: 85 files, 1165 tests, no type errors. The DB-backed integration tests could not be run here — better-sqlite3 is currently built for Electron's ABI rather than Node's, from running the app — so CI is the check on those.

All three tombstone jobs were also run end to end against a real X account.

(This was written by an LLM.)

🤖 Generated with Claude Code