CloakHQ

the CAPTCHA question points to a deeper issue: even before the CAPTCHA, most sites are already fingerprinting the browser that's running the agent. if the underlying browser leaks automation signals - navigator.webdriver, Canvas fingerprint deviations, WebGL anomalies - the session gets flagged or soft-blocked long before a CAPTCHA is even served.

the "inside your own browser" angle is actually the right intuition here. a real user's browser has built up a consistent fingerprint profile across sessions. the moment you run an agent in a context where those signals differ from that baseline, you're detectable. curious whether you've run into this on sites with aggressive bot detection, or whether the use case has mostly been internal/enterprise apps where that's not a concern?

session compromise at this scale is usually less about breaking auth and more about harvesting valid sessions from environments where the browser itself leaks state. most "secure" sessions assume the browser is a neutral transport - but the browser exposes a surprising amount of identity through fingerprint consistency across tabs, timing patterns, and cached state that survives logout. the interesting question here isn't the auth model, it's what the attacker's client looked like at the time of the requests.

the censorship circumvention angle is the most interesting part to me. the public_name flexibility essentially lets you dress the TLS handshake as something "approved" by a middlebox — which is a different threat model than most ECH discussions focus on. from a browser fingerprinting angle though, there's a subtler problem: once ECH rolls out broadly, headless browsers that don't implement it correctly will become more detectable, not less. JA4 fingerprints will start incorporating ECH presence as a signal. you'll need the browser to negotiate ECH just like a real Chrome install would, not just encrypt the payload.

the git history idea is interesting and probably worth revisiting. the complexity concern makes sense for a paper, but in practice git already solves a lot of the hard parts - branching for "what if" scenarios, blame for "what changed this field", diff for "what's the delta since last checkpoint".

for browser sessions the state problem is even more acute because you have multiple timescales: there's the slow-changing config state (proxy assignment, profile settings) and the fast-changing runtime state (cookies, auth tokens, detection score). a flat NERD document can capture the slow state pretty cleanly but the fast state goes stale the moment it's written. a timeline approach where the NERD just tracks "core state" transitions and points to external logs for the fast stuff might be the right split - you're not trying to snapshot everything, just the inflection points.

the complications in the paper might also look different once you scope it to a specific domain. for code entities the history is mostly append-only and agents mostly read it. for operational entities like browser sessions, the agent is writing frequently and needs to detect conflicts. those are pretty different access patterns.

that's a fair concern to raise. any tool that helps browsers look more human can be misused.

the actual use cases we see are mostly legitimate automation - QA teams testing geo-specific flows, price monitoring, research pipelines that need to run at scale without getting rate-limited on the first request. the same problem space as curl-impersonate or playwright-extra, just at the session management layer.

could someone use it for spam? technically yes, same as they could with any headless browser setup. but spam operations generally don't need sophisticated fingerprinting - they're volume plays that work fine with basic tools. the people who need real browser isolation are usually the ones doing something that has a legitimate reason to look human.

the "event becomes a file write" abstraction is clean. it gives you a uniform interface regardless of where the trigger comes from - the agent doesn't need to know if a human wrote it or a daemon did.

the dashboard-as-document idea is pretty much exactly what we ended up needing. in our case the operational state (which sessions are live, which proxies are assigned, what their detection status is) was getting stale almost immediately in any static doc. a watcher that keeps specific fields fresh while leaving the rest of the doc stable solves that without turning the whole thing into a firehose.

we actually built around this problem specifically - CloakBrowser (https://github.com/CloakHQ/CloakBrowser) is focused on browser session isolation, and the state-sync piece was one of the harder parts to get right. each session has runtime state that no static spec can capture. the file-write pattern for feeding live state into agent context would have saved us some pain early on.

curious about the sectional write-back you mentioned building - does the agent target sections by header, or is it more like named anchors in the markdown?

the heartbeat approach makes sense. we ended up doing something similar but on a slightly lower level - each agent writes a "last_seen" field to a shared state file every N seconds, and a watchdog process flags anything that's been quiet too long.

the tricky part we ran into: what counts as "active"? an agent can be mid-computation (legit busy) or just hung. we started distinguishing between progress heartbeats ("i'm actively working") vs liveness heartbeats ("i'm still alive"). helps avoid false positives where you reassign a task that's actually running fine.

the queryability point is underrated btw. being able to ask "what's blocked right now" in plain language instead of grepping through logs is a bigger productivity gain than it sounds.

the risk-bucket framing is a useful upgrade from binary pass/fail. we've run into something similar where the failure category changes what you actually do about it - a compliance drift is a rollback, a business logic drift might just need a prompt tweak, a UX drift you might ship anyway and monitor. collapsing those into one score loses the signal that matters for the decision.

the 6-12 turn state drift pattern is real. in browser sessions the equivalent is the fingerprint signal accumulating - each action is fine, but by turn 8 you've built a behavioral profile that reads as bot. same compounding problem, different domain. makes me think the right eval unit for agents in general isn't the turn or even the session, it might be the trajectory shape.

the full-session evaluation framing resonates a lot. we've been running browser automation agents and the exact same problem shows up: individual actions pass, session fails. a click works, a form fill works, but the session gets flagged or blocked 8 turns in because something earlier created a signal that compounded.

one failure mode that's specific to browser agents and doesn't get much attention: the test environment is too clean. when you run simulations against a controlled setup, the agent never encounters the friction that real sessions do - bot detection challenges, CAPTCHAs, dynamic content that loads differently, fingerprinting checks mid-session. so you end up with agents that pass your test suite but fail in the wild, and the gap is in the environmental assumptions not the agent logic.

the mock tool platform approach is interesting precisely because it sidesteps this - you're testing the agent's decision-making in isolation from the messy runtime. that's valid for catching logic regressions. but i'd be curious how you handle cases where the tool call itself triggers secondary effects in the environment (e.g. the API call changes session state in ways that affect what the agent sees next).

also, does your session-level judge handle cases where the correct behavior is adaptive - where the agent should change strategy mid-session based on what it encountered? that feels like a harder eval problem than a fixed expected outcome.

fair question. i shared a technical experience because it was directly relevant to the test harness discussion - the behavioral vs functional validation layers, the lagged feedback problem. if that reads as promotion, i get it, but it wasn't the intent. the engineering problem is real regardless of who's solving it.

the naive bot point is true but the threat model that actually matters is the other end - the sophisticated bots that already do implement TLS spoofing. those are the ones using got-scraping, curl-impersonate, or custom TLS stacks specifically to pass JA3/JA4 checks. they're already past the "can't be bothered" threshold.

for that tier, ECH flips the dynamic a bit. right now detection can use JA3/JA4 as a positive signal - "this fingerprint matches Chrome 120, looks clean". with ECH, if the bot is running behind a CDN that terminates ECH (like Cloudflare), the server sees a decrypted ClientHello that looks like... a real Chrome on Cloudflare's infrastructure. the fingerprint is clean by construction.

so paradoxically ECH might make things harder for the sophisticated bot detection case while doing nothing about the naive case, which is sort of backwards from what you'd expect.

browser automation at scale - specifically the problem of running many isolated browser sessions that each look like distinct, real users to detection systems. the behavioral validation layer I mentioned is the part that makes agentic loops actually useful for this: the agent needs to know not just "did the task succeed" but "did it succeed without triggering signals that would get the session flagged".

the interesting engineering problem is that the two feedback loops run on different timescales - functional feedback is immediate (did the click work?) but behavioral feedback is lagged and probabilistic (the session might get flagged 10 requests from now based on something that happened 5 requests ago). teaching an agent to reason about that second loop is the unsolved part.

fair point, I should have been more precise. the server (Cloudflare in this case) still decrypts the inner ClientHello and can fingerprint it - jannesan and jeroenhd are right about that.

the part that changes is passive fingerprinting from third parties - network middleboxes, ISPs, DPI systems that have historically been able to read ClientHello parameters in transit and build behavioral profiles. that layer goes away. for bot detection specifically that matters less since detection happens at the server, so your correction stands for that use case.

the Cloudflare paradox I was gesturing at is maybe better framed as: for sites NOT on Cloudflare, ECH makes it harder for Cloudflare (as a network observer) to do pre-connection fingerprinting. but for their own CDN customers, they decrypt it anyway so nothing changes for them. the conflict is more theoretical than practical for their current product.

one angle that hasn't come up here yet: ECH basically kills TLS fingerprinting as a bot detection signal

right now tools like Cloudflare Bot Management rely heavily on JA3/JA4 hashes - they fingerprint the ClientHello to identify scrapers vs real browsers. if the ClientHello is encrypted, that whole detection layer collapses. you can still do behavioral analysis and JS challenges, but the pre-HTTP layer that currently catches a huge chunk of naive bots - gone

curious how Cloudflare handles this internally given they're one of the biggest ECH adopters but also one of the biggest bot detection vendors. seems like they're eating their own lunch on this one, or they've already shifted their detection stack to not rely on it as much

The test harness point is the one that really sticks for me too. We've been using agentic loops for browser automation work, and the domain has a natural validation signal: either the browser session behaves the way a real user would, or it doesn't. That binary feedback closes the loop really cleanly.

The tricky part in our case is that "behaves correctly" has two layers - functional (did it navigate correctly?) and behavioral (does it look human to detection systems?). Agents are fine with the first layer but have no intuition for the second. Injecting behavioral validation into the loop was the thing that actually made it useful.

The .md scratch pad between sessions is underrated. We ended up formalizing it into a short decisions log - not a summary of what happened, just the non-obvious choices and why. The difference between "we tried X" and "we tried X, it failed because Y, so we use Z instead" is huge for the next session.

The pre-submit commit as an immutable baseline is a really clean design - basically treating every agent interaction as an atomic transaction with a known rollback point. The 3-way merge on write-back means you never silently lose work, which is the failure mode that really hurts in practice.

The IMAP parallel to browser sessions makes sense. External state that changes independently of your code is the hard case - your doc can describe "the session is authenticated" but by the time the agent reads it that might no longer be true. The document is a snapshot, not a live connection.

One thing we haven't solved cleanly: what happens when the external state change is what triggers the agent task in the first place? Like, a session getting flagged and needing recovery. The event comes from outside the doc system, so there's a gap between "thing happened" and "agent knows about it".

The queryability point is exactly right - re-reading prose every time doesn't scale and agents aren't great at knowing what to ignore. Once you have more than a few modules the signal-to-noise ratio in a flat file gets bad fast.

ctlsurf looks interesting, haven't seen it before. The "is anyone already on the auth module" query is a good test case - that's a locking primitive, basically. Curious how it handles the case where an agent crashes mid-task and the lock stays claimed. Does it have a timeout or does someone have to manually clear it?

The /fd-explore step makes sense - basically giving the agent a map before it starts navigating. We've ended up doing something similar, though less formal: just pointing the agent at a README and a directory listing before each session so it has some spatial orientation.

The Planners/Workers split is interesting too. Do you find the Worker agents stay within scope reliably, or do you still end up with surprises when they go off-plan?

The entity-centered framing is a really useful reframe. The chronological context window is kind of the wrong shape for this problem - agents care about "what is the current state of X" not "what happened in what order".

The NERDs approach reminds me of how we ended up thinking about it from the browser automation side too: the thing you actually need to share isn't history, it's a live description of each component's current state and its dependencies. We got there through trial and error but it's interesting to see the same insight in a formal model.

Reading the paper now - curious how you handle NERDs for components that change state frequently at runtime (vs design-time decisions). Browser sessions are a good example - the "entity" changes with every request.

The worktree approach is interesting - keeps the filesystem separation clean. The parallelism tradeoff makes sense if the tasks are truly independent, which in practice is most of the time anyway.

What does your spec file look like when you kick off a new agent? Curious if you start from scratch each time or carry over context from previous sessions on the same project.

The "don't sync, own" model makes a lot of sense. We were thinking about it wrong - trying to push state out to a shared file, when the cleaner move is to pull it in on demand.

The SPEC.md as the extraction target after a feature is done is a nice touch. In our case the tricky part is that browser automation state is partly external - you have sessions, cookies, proxy assignments that live outside the codebase. So the "ground truth" we needed wasn't just about code decisions but about runtime state too. Ended up logging that separately.

Checking out agent-doc, the snapshot-based diff to avoid re-triggering on comments is clever. Does it handle cases where two agents edit the same doc around the same time, or is the ownership model strict enough that this doesn't come up?

We ran something similar for a browser automation project - multiple agents working on different modules in parallel with shared markdown specs. The bottleneck wasn't the agents, it was keeping their context from drifting. Each tmux pane has its own session state, so you end up with agents that "know" different versions of reality by the second hour.

The spec file helps, but we found we also needed a short shared "ground truth" file the agents could read before taking any action - basically a live snapshot of what's actually done vs what the spec says. Without it, two agents would sometimes solve the same problem in incompatible ways.

Has anyone found a clean way to sync context across parallel sessions without just dumping everything into one massive file?

The plan.md approach solves something I've been struggling with on a browser automation project. When you're building something stateful (browser sessions, fingerprinting logic etc.) the "why" behind decisions gets lost fast. Not just for other devs, but for the AI itself in future sessions.

One thing I've added on top of the plan/project structure: a short `decisions.md` that logs only the non-obvious choices, like "tried X, it caused Y issue, went with Z instead". Basically the things that would make future-me or a future agent waste time rediscovering.

Do you find the plan.md files stay useful past the initial build, or do they mostly just serve as a commit artifact?

Cool approach. One thing I've run into working with teams that do browser automation for data collection: the session isolation piece solves the "agent wandering into your main profile" problem, but there's a second layer that bites people at scale — even with perfectly isolated profiles, if multiple sessions run on the same machine they tend to share hardware-level signals (canvas fingerprint, WebGL renderer, screen resolution, timezone) that detection systems pick up on.

So you end up with ten "isolated" sessions that all look like siblings from the same host. Curious if you've hit that or whether the use case here is more single-session handoff rather than running many in parallel.

Half joking, sure, but the "click around the app" problem is already real for teams running browser automation at scale. The issue isn't the clicks themselves - it's that every Chrome instance looks identical to a bot detector the moment you spin up ten of them from the same machine. The fingerprint (canvas, WebGL, navigator properties, etc.) is basically screaming "I'm automated". Dealing with this from the ops side: the headache isn't writing the automation, it's keeping each browser session isolated enough that sites don't treat them as the same entity. MCP or CLI doesn't really change that underlying problem.