fix(stealth): handoff() uses the shared profile resolution + lock cleanup

The headless-to-headed handoff path hardcoded ~/.gstack/chromium-profile,
silently ignoring $CHROMIUM_PROFILE and $GSTACK_HOME (gbrowser's gbd sets
per-workspace profiles), and skipped cleanSingletonLocks() — so a handoff
into a profile with a stale SingletonLock could hang where launchHeaded()
would have recovered.

This was the third live drift between the three Chromium launch paths; the
first two are documented in comments as shipped stealth regressions. Minimal
targeted fix — the full buildLaunchConfig() extraction stays in the deferred
queue.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Garry Tan 2026-08-14 19:16:57 -07:00
parent dd66e4cda2
commit 5c806a4bd7
No known key found for this signature in database
GPG Key ID: C1F69E85C74EFE1D
1 changed files with 6 additions and 1 deletions

View File

@ -1568,8 +1568,13 @@ export class BrowserManager {
console.log('[browse] Handoff: extension not found — headed mode without side panel');
}
const userDataDir = path.join(process.env.HOME || '/tmp', '.gstack', 'chromium-profile');
// Same profile resolution + singleton-lock cleanup as launchHeaded().
// This path previously hardcoded ~/.gstack/chromium-profile, silently
// ignoring $CHROMIUM_PROFILE / $GSTACK_HOME and skipping the lock
// cleanup — the third shipped drift between the three launch paths.
const userDataDir = resolveChromiumProfile();
fs.mkdirSync(userDataDir, { recursive: true });
cleanSingletonLocks(userDataDir);
// T1: same automation-tell-stripping defaults as launchHeaded().
// The handoff path (headless → headed re-launch) takes the same