Browser automation depends on a profile directory with ownership markers designed to prevent concurrent writers. When a container is recreated, those markers can survive while the process IDs refer to a different PID namespace. The reported recovery code treated a foreign owner as alive and refused to launch. Removing every lock blindly would be unsafe for…
Inspect the ClaimsCase · DiggingBeagle record
Hermes browser sessions can mistake stale Chromium profile locks for living owners
A container-recreate report shows browser agents refused access to persistent profiles because old PID and lock metadata were treated as active owners.
Scope
One reported setup and its reproduction are available; no general incidence or merged upstream fix is established.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade D
- AI role
- AGAINST AI
Basis and provenance
The pinned Claim and its primary disclosure support the described controlled result, but do not establish a population-wide rate or calibrated impact. The only available supporting evidence is the reporter's or advisory author's own account; independent reproduction has not been shown. Impact remains unbanded because no calibrated impact rubric for this particular evidence is established.
Assessed Nov 2, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV02-HERMES-CHROMIUM-STALE-LOCK-A · Hermes Agent issue 147739: stale Chromium lock after container recreate
At a glance
Browser ownership and recovery must be fenced by a stable process or container epoch rather than trusting stale numeric PIDs alone.
Read the implicationsOne reported setup and its reproduction are available; no general incidence or merged upstream fix is established. A corrected upstream ownership check and its behavior for genuinely concurrent profile users have not been established.
Limits and uncertaintyFull account
Browser automation depends on a profile directory with ownership markers designed to prevent concurrent writers. When a container is recreated, those markers can survive while the process IDs refer to a different PID namespace. The reported recovery code treated a foreign owner as alive and refused to launch. Removing every lock blindly would be unsafe for genuinely shared profiles, so the real boundary is between a verified live process and stale persisted metadata.
Container recreation can preserve a Chromium profile volume while replacing the PID namespace that originally created its lock. A liveness check in the new container cannot automatically treat a PID from the old namespace as a live owner, nor can it safely delete every foreign-looking lock. The reported failure leaves the browser unavailable to otherwise healthy agents, so a supervisor heartbeat alone is not evidence of usable browser capability. The repair requires a provenance-aware profile lease or a guarded ownership test rather than an unconditional lock-file cleanup.
Mechanism and trust boundary
- 01
Persist browser profile state
The profile directory retains lock and last-launch information.
Boundary: Browser session into durable filesystem
- 02
Recreate the container
Old PIDs no longer describe a live process in the new namespace.
Boundary: Process identity across container epoch
- 03
Reject new browser launch
Liveness checks treat stale metadata as a valid foreign owner.
Boundary: Unverified process identity into service availability
Claims & evidence
CLM-2026-NOV02-HERMES-CHROMIUM-STALE-LOCK-AThe reporter observed browser-launch failure on seven of ten agents after a container replacement, although the previous process namespace no longer contained a working Chromium.supported
Basis: reported finding
- supportsHermes Agent issue 147739: stale Chromium lock after container recreateprimary disclosure
Issue 147739, shared profile SingletonLock and post-recreate liveness reproduction
Implications
Browser ownership and recovery must be fenced by a stable process or container epoch rather than trusting stale numeric PIDs alone.
Controls and mitigations
- Confirm real process ownership before clearing locks; use isolated profiles and guarded restart diagnostics.
- Keep one profile per worker identity, verify the real process and namespace before reclaiming a lease, and separately health-check browser launch.
Unknowns and contradictions
- One reported setup and its reproduction are available; no general incidence or merged upstream fix is established.
- A corrected upstream ownership check and its behavior for genuinely concurrent profile users have not been established.
Sources and citation
Material revision history
- Nov 2, 2026 · Canonical change recorded · new in release · revision 214