Browser continuity

Why MCP alone is not enough for long-running Web work.

MCP gives a Web AI a way to call tools on the workstation. It does not guarantee that a browser conversation will keep running after a long local task finishes.

That distinction matters for Herdr workflows.

MCP direction
Web AI ─────────────► workstation

Continuity direction
workstation ────────► browser conversation

A durable AI development workflow needs both directions.

The long-task gap#

Consider a typical task:

ChatGPT inspects a repository.
It dispatches a focused implementation task to a Herdr agent.
The tool call returns quickly: the job was accepted.
The browser turn ends.
The local agent keeps working for another 20 minutes.
The agent finishes.

At step 6, nothing in standard request-driven MCP automatically starts a new ChatGPT turn. The local machine knows that work finished; the browser does not.

This is the gap the extension closes.

Continuity is not another agent#

The browser extension does not replace ChatGPT, Herdr or the local worker. It does not own project planning or code-generation policy.

Its job is narrower:

bind a browser scope to a Herdr workspace — a stable ChatGPT Project where available, otherwise a concrete conversation;
observe local progress and settled state;
feed useful progress back into the right conversation;
recover a browser view that stalled or lost part of a response;
hand a very long conversation to a fresh conversation safely;
keep the right browser conversation connected to that local work over time.

The Web model remains the planner. Herdr remains the runtime truth. The extension keeps the two sides connected over time.

This boundary is the main reason the extension exists. A ChatGPT tool round can dispatch an Agent and then end; the Web planner cannot keep polling after that assistant response has been sent, and Herdr cannot directly start a new model turn. The extension therefore treats local state changes as continuation signals. A meaningful output change may produce a bounded progress wake; a working → idle/done/blocked transition wakes once; reconnect can recover a settle that happened while the browser/runtime link was unavailable. The wake tells the Web planner to re-read live Herdr/Git state, inspect the Agent result and diff, review/cherry-pick or merge isolated completed work where appropriate, and run the task's acceptance checks. A blocked/failed/timeout-like result remains work to diagnose; the wake itself is never completion evidence.

That behavior is a compatibility contract across Rust/runtime changes. Regression coverage must keep the browser binding, one-shot settle semantics, progress deduplication, stale-source rejection, Native Messaging trust boundary, handoff/queue migration, and extension-version alignment intact whenever local runtime or event transport code changes.

Why the binding is a workspace, not an agent#

Real work often involves more than one pane:

workspace: my-project
  ├─ pane: pi implementing a fix
  ├─ pane: test suite
  ├─ pane: local server
  └─ pane: grok reviewing the diff

Binding the browser to one agent would lose the rest of the project state. A workspace is the better unit of continuity because it represents the complete local work area.

The binding stores the stable workspace identity; the label is only presentation data and can be refreshed from the live workspace catalog. ChatGPT adds one more level: a Project binding is keyed by stable project_id, while active_conv_key points at the concrete conversation that should receive messages. This lets the user bind from the Project home before creating a chat and lets rollover keep the binding itself stable.

Progress and settled events#

During long work, the extension can send progress updates when there is meaningful new local output. When the bound workspace settles, it can wake the Web conversation once so the planner can inspect results, integrate completed Agent work when appropriate, run acceptance checks, and decide what to do next.

The important rule is to avoid turning continuity into notification spam. Progress checks and progress sends are different concepts: the extension may check frequently but only send when there is new information or a configured fallback interval has elapsed.

Browser recovery#

A Web AI turn can also fail on the browser side while the server-side conversation has already advanced. Examples include:

an explicit send-timeout error;
a response stream that disconnected;
the page showing only a stale partial answer;
the server having a newer assistant message than the current DOM.

Blindly resending the user task is dangerous because tool mutations may already have happened.

The recovery policy is therefore evidence-first:

error / stale view
      ↓
inspect same-origin conversation state when possible
      ↓
server already advanced? → refresh view
request clearly not accepted? → bounded retry
unknown delivery? → fail closed
      ↓
only after recovery is exhausted consider handoff

The goal is not maximum automation. The goal is preventing duplicate work while still recovering from ordinary browser failures.

Conversation rollover#

A productive Herdr session can outlive one ChatGPT conversation. Tool calls, project instructions and visible text all consume context, while the browser may virtualize older messages and stop keeping the entire history in the DOM.

From 0.4.2, finalized user and assistant turns from a bound conversation are appended incrementally through Native Messaging into the Rust state.db Continuity Journal. Before an ID-only rollover, the extension performs a live Rust resolve for the current continuity_id. When that resolve succeeds, the fresh conversation receives only the compact continuity reference, calls the existing herdr_call(method="continuity.resume", ...) path to recover a bounded recent working tail, and then re-inspects Herdr, Git and relevant services before mutation.

A user who manually starts another conversation inside the same bound ChatGPT Project does not need to remember or type the continuity_id. The first accepted user turn in the new conversation (for example, “continue”) is journaled through the existing Project binding onto the same continuity chain. When the Web planner sees prior-work intent such as “continue”, “resume”, or “where did we leave off?”, it searches with continuity.resolve / continuity.search before asking the user for an internal ID. Automatic continuity.resume is allowed only when stable conversation/project/workspace identity yields exactly one active chain. A text-only match remains confirmation-required even when it returns a single candidate; a generic word such as “continue” is a search trigger, not selection evidence. Ambiguous results expose only bounded title/workspace/update-time and recent-turn evidence for user confirmation, and Herdr never chooses by newest-or-most-similar heuristics.

Handoff has one durable recovery payload. herdr_mcp.browser_handoff.prepare reuses the existing continuity_id, keeps the exact old ChatGPT URL as source_url, and returns one compact continuation message for both automatic delivery and Copy Prompt fallback. A user without browser automation can open a new Web-AI conversation and paste that same message. The old URL also remains a standalone recovery anchor: when only the URL is available, the planner can call continuity.resume with the full URL as conversation_url; only continuity_ambiguous falls back to bounded continuity.search. This recovery does not depend on ego-browser or prior endpoint/account/Project/generation/device enumeration. A private ChatGPT conversation that was never captured into the local journal cannot be fetched from its URL through MCP alone because the MCP connection does not carry the user's private ChatGPT session body.

The continuity id identifies one stable work chain across conversations. On ChatGPT Projects the Project/workspace binding and continuity id stay in place while only the confirmed active conversation target changes.

If the local journal is unavailable or live Rust resolve fails, a new ChatGPT handoff fails closed while preserving the source conversation and full source URL. It no longer asks the source WebChat or a fallback LLM to generate a handoff summary. HERDR_HANDOFF_V1 remains read/recovery compatibility only for already-existing legacy transfers and provider-specific legacy contracts such as z.ai; new ChatGPT handoffs do not create it.

This preserves continuity without making the dying source page responsible for the only recoverable copy of working state.

1.0 Work Memory and continuity compaction#

The 1.0 runtime extends the Continuity Journal with Project Work Memory and verified rolling checkpoints. Finalized raw turns remain durable continuity evidence, while work_memory.checkpoint.put writes a compact structured checkpoint under checkpoint-revision CAS and requires a real message/evidence anchor from the same Work Memory partition.

work_memory.resume resolves the exact project_ref + repo_id + work_chain_id partition and returns the latest verified checkpoint together with a bounded recent raw tail and local evidence. This keeps long-running recovery bounded without creating a second task-state authority. Browser handoff continues to reuse the same continuity_id; provider-native Memory is never the recovery authority.

Older raw bodies may be reclaimed only after replacement checkpoint evidence has been generated and verified. Browser memory, long-DOM cost, main-thread/render pressure, and model context pressure can inform rollover, but they do not change Work Memory authority or replay safety. Reliability-kernel generation, idempotency, delivery, and uncertain-result rules protect checkpoint mutations. The original design provenance remains in Phase 8 of the Rust Native Rearchitecture document and the 1.0 Alpha 2 Work Memory design.

Manual and automatic control#

Automation is scoped deliberately.

For ChatGPT Projects, automation can be shared at the Project level when the global Project permission is enabled. Normal ChatGPT conversations, z.ai and DeepSeek use conversation-level settings where supported.

New scopes default to Auto off. The HUD's three preset progression actions are mutually exclusive with automatic progression so the same conversation is not advanced by two paths at once. Handoff is the deliberate exception and has one UI entry in the HUD: where supported, it can start with Auto on or off, pauses automatic wakes from the source during transfer, and makes the target inherit the source Auto state.

Manual takeover remains important. The user can turn Auto off to continue manually, extract Herdr status, or run the lightweight LLM judge from the HUD; an explicit handoff starts from Control Center where supported.

Why local Native Messaging is used#

The extension should not need the workstation bearer in browser storage.

The primary path is:

content script
  ↓
extension service worker
  ↓ Chrome Native Messaging
native host
  ↓ local Unix socket (0600)
herdr-mcp runtime

The browser does not route continuity traffic through the public Cloudflare Edge. This keeps public OAuth identity and local extension trust as separate security boundaries.

Continuity is one extension surface, not the whole browser product#

This page focuses on Web continuity: workspace binding, progress / settled push-back, stale-view recovery, and handoff / rollover.

The extension now has two other product surfaces with different responsibilities:

Browser Control Center — live workspace / pane / agent observation, explicit Pinned Target, and bounded reads in Chrome Side Panel;
JSON → MCP bridge — a local tool compatibility path for z.ai / DeepSeek when the site does not expose a native MCP Connector.

They share Native Messaging and local IPC, but they are not one state machine. Continuity decides how a Web conversation persists; Control Center presents local truth and explicit human targeting; JSON → MCP adapts tool protocol.

The mental model#

Think of Herdr as the persistent workshop, MCP as the remote-control cable, and browser continuity as the return signal that tells the Web planner when the workshop changed.

With all three pieces in place, a long coding task no longer has to fit inside one synchronous browser turn.

Browser extension — installation and the full browser-product overview
Browser Control Center — Side Panel live state and explicit targeting
Wake, recovery and handoff — continuity state machine and current behavior
JSON → MCP bridge — z.ai / DeepSeek compatibility path

Continuity implementation and recovery details#

Role: advanced reference for the browser continuity state machine. Most users only need Browser Extension and Browser Control Center.

This page describes the browser continuity state machine: how the extension wakes the correct Web conversation when Herdr work continues after a browser turn ends, how it recovers stalled ChatGPT views, and how it hands a long conversation to a fresh one without duplicating mutations.

Read Browser Continuity first for the architectural motivation. Installation and HUD usage are covered in Browser Extension.

Bind a Project or conversation to a workspace#

Continuity binds a browser scope to a Herdr workspace, not to a single agent. For normal conversations that scope is the conversation itself. For ChatGPT Projects it is the stable project_id.

ChatGPT conversation
        │ binding
        ▼
Herdr workspace
  ├─ implementation agent
  ├─ test process
  ├─ server/log pane
  └─ review agent

workspace_id is the stable identity. The label is presentation metadata and is refreshed from the live catalog.

Since 0.1.59, a ChatGPT workspace can be bound directly from https://chatgpt.com/g/<project>/project before any conversation exists. The Project binding persists independently; a concrete active /c/<id> becomes only its active_conv_key delivery target. https://chatgpt.com/ can also hold a tab-scoped pending binding which migrates once when that tab first enters a Project or conversation. Root and Project-home pages expose binding controls but do not run conversation-only Continue/LLM/recovery/rollover actions.

working, progress and settled#

The extension observes local /push/events through the trusted Native Messaging path.

working#

When any relevant agent in the bound workspace becomes working, the extension arms progress observation.

progress#

progressTickSec controls how often progress is checked, not how often a message is guaranteed to be sent.

A progress message is sent when there is meaningful new output, or after the configured fallback interval. The last sent summary and timestamp are persisted so a Service Worker restart does not cause repeated notifications.

settled#

If one pane settles while other agents in the workspace are still working, that is partial progress. The workspace is considered settled only when the relevant working set becomes empty.

A settled event wakes the Web planner so it can inspect Git, tests and agent output. The event itself is not proof that business acceptance criteria passed.

Manual HUD actions#

The HUD can expose:

Continue — send a simple continuation to the current Web conversation;
Herdr monitor — inspect the bound workspace before continuing;
LLM analysis — ask a small configured model whether the latest reply is clearly unfinished;

The HUD exposes Continue / Check Herdr / LLM decide plus Handoff. The first three page-scoped progression actions are locked while Auto is on; Handoff remains available when its safety gates pass. Workspace binding and local Herdr controls stay in the Side Panel. Handoff has a single UI entry in the HUD, pauses source automatic wakes during transfer, and makes the target inherit the source Auto state.

Queue: explicit next-turn user intent comes before auto-continue#

Queue beside the ChatGPT composer is different from the HUD's manual Continue action.

Queue is for the case where the assistant is still replying but the user already knows what the next instruction should be. Clicking it does not interrupt the live turn; it persists the current composer text for that conversation.

When the turn settles, ordering is:

current assistant turn ends
       ↓
queued content? ── yes ──► merge and send the next user message
       │ no
       ▼
then consider semantic Auto: Jev -> LLM -> bounded script fallback

This priority is deliberate: an explicit next-turn user instruction outranks the model deciding for itself whether to continue.

The queue also follows these bounds:

entries preserve insertion order and merge with blank lines;
a turn-in-progress or other blocked delivery does not ACK or drop content;
only a confirmed delivered batch is removed;
entry count, per-entry length, and merged length are bounded;
right-click Queue to clear the current conversation queue;
click with an empty composer to retry a still-pending batch;
after handoff cutover is confirmed, pending content migrates to the target conversation in the same order.

Queue does not execute a Herdr tool or change workspace binding. It only preserves and delivers the next user message.

Automation scope#

ChatGPT Projects#

Project automation requires both:

global permission for ChatGPT Project automation in Options;
the current Project HUD set to Auto on.

The preference is keyed by stable project_id, so a handoff conversation in the same Project can inherit the Project automation setting.

Herdr tool permission cards are the one exception that does not follow Auto: a supported, explicitly labeled Herdr tool permission card is accepted automatically even when Auto is off, because it only unblocks a tool invocation the Herdr connector itself requested and reuses the fail-closed card detector. Auto continues to govern wake/progress/rollover behavior; turning it off never leaves a tool call stuck behind a card.

Normal ChatGPT / z.ai / DeepSeek#

Where supported, these use conversation-scoped Auto.

z.ai and DeepSeek Auto only performs Herdr progress/settled wake behavior. ChatGPT-specific stale-view recovery, permission-card handling, end-of-turn semantic judgement and automatic rollover are not treated as generic capabilities.

Asynchronous parent wake for Agent tasks#

When ChatGPT dispatches long-running local Agent work through herdr_prompt, the stable browser session identity travels with the request into Runtime. Runtime immediately returns task_id / dispatch_id / turn_id and later persists the terminal result in the durable parent inbox. The extension still uses Herdr settled events as a cheap trigger, but task ownership, completed / blocked / failed, Jev advisory, and HUD task counters come from the session-scoped inbox; only tasks owned by the current browser_session_ref can wake that conversation. A task is acknowledged only after wake delivery succeeds, so extension downtime or a failed wake leaves the durable result pending.

When the inbox contains unacknowledged terminal work, Runtime may evaluate one bounded agent.attention.advise batch for up to 16 scoped child summaries, including active siblings. The result is attached to the inbox as Parent guidance: verify_completion enters deterministic validation, continue_unobserved leaves independent running siblings alone, and human/blocker/drift states direct the next observation. Terminal facts still wake the Parent immediately; the Browser no longer waits for a second semantic grace or applies its own probability thresholds. If Jev is unconfigured, slow, malformed, or fails, the same deterministic terminal wake proceeds.

End-of-turn semantic judgement#

A ChatGPT reply can be syntactically finished while semantically unfinished: for example, it may say that tests still need to run or that the next step is to inspect Git.

For ordinary Auto, the decision path is fixed and progressive:

deterministic safety / scope gates
        |
        v
TypeSafe Jev / System One, when configured
        |
        v uncertain / unavailable
OpenAI-compatible LLM judge, when configured
        |
        v ambiguous / unavailable
bounded mechanical script fallback

Jev answers the narrow semantic question first; a clear high-confidence continue/done result is final for ordinary Auto. The LLM judge handles cases Jev cannot settle. The script fallback is deliberately less accurate and exists so Auto still has basic behavior when neither provider is configured or both semantic stages are unavailable. Script heuristics never override a Jev/LLM result.

The extension does not configure provider endpoints, models, or API keys. It calls the local Herdr Runtime semantic service. Provider configuration has exactly two layers: mode-0600 config.json for the workstation and the authenticated Cloudflare Worker route pool shared across enrolled workstations; local routes take precedence per typed/chat capability. Both layers use the same name / protocol / url / model / api_key route JSON object; decision and decision-vercel imply typed evaluation, while openai-chat implies chat; shell/process environment is not a provider configuration source. Configuration order is route priority; later routes are bounded fallbacks after failure/cooldown. Typed and chat routes share bounded per-route attempts, separate total deadlines, cooldown, and serial failover.

Goal-aware automation keeps a stronger boundary. Jev can provide one bounded five-signal semantic prior — can_continue, needs_human, waiting_external, task_completed, needs_handoff — to the existing LLM Goal Supervisor. Those probabilities are advisory only. Work Memory/TODO evidence and deterministic runtime guards remain authoritative for completion, waiting, handoff, human boundaries and uncertain delivery.

Recovery is evidence-first#

A stalled browser does not mean the server never accepted the request.

The user message, tool mutations or assistant response may already have progressed server-side while the DOM stayed stale.

The recovery sequence is therefore:

browser appears stalled
        │
        ▼
best-effort same-origin conversation snapshot
        │
        ├─ server ahead ───────► safe reload
        ├─ request not accepted ► bounded Retry
        ├─ server stalled ─────► wait, then one reload
        └─ unknown ────────────► fail closed

Unknown delivery never justifies blindly resending the original task.

Stale view: server ahead of the DOM#

The extension can compare the last visible assistant message with the same-origin conversation snapshot: message identity, text length, completion state and update time.

server ahead — the server has a newer or longer message; reload once to synchronize the view;
server stalled — the server itself still shows an incomplete assistant turn with no progress; wait conservatively before one reload;
synced — server and DOM agree; no recovery action;
unknown — snapshot unavailable or ambiguous; fail closed.

Reloading is meant to reveal an existing server-side turn, not to resubmit the user's task.

Explicit send-timeout errors#

When ChatGPT renders a send-timeout/thread-error card, the extension first checks server-side conversation state.

If current_node already moved to an assistant message, the request was accepted; Retry could duplicate tool work, so the safer action is a view reload.
If current_node is still the user message, ChatGPT's own Retry may be used once.
If delivery cannot be determined, prefer bounded view synchronization over creating another user turn.

Retry and reload budgets are finite. Exhausted recovery becomes an explicit failure/rollover recommendation rather than an infinite loop.

Interrupted response streams#

If the assistant started responding but the page reports a disconnected stream, the error placeholder itself is not progress. Only assistant text growth or signature change advances the progress clock.

After a conservative stall window and only when the page is otherwise safe, the extension may reload once to resynchronize the existing server-side turn. It does not resend the original task.

Page-health self-recovery: stalls, memory and 429#

Version 0.1.63 connects the previously diagnostic-only UI-pressure meter to a strictly bounded page-health recovery layer. It does not delete ChatGPT/React-owned history DOM. Removing those nodes behind React can desynchronize the framework tree, event handlers, virtualization state and the real DOM; when the whole page runtime needs reclamation, a controlled reload is safer because it rebuilds the document, React tree and JS heap together.

The fixed-window O(1) signals are MutationObserver callback rate, watcher tick rate, timer drift, Long Tasks and, when Chromium exposes it, JS heap usage. A single spike is observational only.

An active turn becomes reload-eligible only after sustained page pressure plus a real assistant stall, and only when the same-origin conversation snapshot proves current_node is a finished assistant. That proof is what allows a stale Stop/streaming UI bit to be ignored as a renderer problem rather than live work.
Critical heap pressure is eligible only after a quiescent interval. Manual composer text, tool execution, permission cards and uncertain delivery always block reload.
Level one is at most one durable location.reload(). If the same health failure survives that refresh, level two is at most one sender-scoped chrome.tabs.reload(tabId). The background worker accepts only its actual sender.tab, the same conversation, Auto enabled and a matching durable pending record, then persists executed-at before navigation so MV3 worker restart cannot create a reload loop.
Exhausting both levels stops further reloads and recommends controlled conversation rollover instead.

HTTP 429 is the opposite kind of signal: 429 is backoff-only and never a Retry/reload trigger. A visible rate-limit error or a Resource Timing 429 enters a 30s → 60s → 120s capped cooldown. Automatic recovery does not create additional page/API/attachment traffic during that cooldown, avoiding a rate-limit amplification loop.

Context pressure and automatic rollover#

Long Herdr sessions can accumulate visible text, MCP payloads, Project instructions and hidden system context. ChatGPT may also virtualize old DOM nodes, so a short current DOM is not evidence of a short conversation.

The extension uses conservative pressure signals:

approximate visible user/assistant tokens;
maximum absolute conversation-turn-N index still observable;
a persisted monotonic message-count floor;
reserved headroom for Project/system/tool payloads not visible in the page.

High pressure only makes rollover eligible. Automatic handoff still requires a safe boundary: Project Auto on, any bound workspace not working, no stream/tool/permission card, no unsent manual draft, no uncertain delivery and no other handoff in progress. Handoff itself does not require a workspace binding; durable continuity plus the current supported conversation identity is sufficient.

Fail-closed handoff#

old Project conversation
        │ generate compact packet with transfer id
        ▼
new conversation in the same Project
        │ submit seed packet
        ▼
verify new conversation id + seed marker
        │
        └── only then switch Project active_conv_key

The Project/workspace binding and continuity_id remain stable. The old active conversation remains authoritative until the new conversation is verified. z.ai is still conversation-scoped, so its binding moves only after the target seed is confirmed.

Opening a new tab is not enough. Attempting to send the seed is not enough. If seed delivery is uncertain, the old binding stays in place and the transfer remains recoverable.

What belongs in a handoff packet#

A useful packet preserves:

current objective;
completed work;
important decisions;
incomplete work;
known workspace/path/branch/commit/task identifiers;
safety constraints;
recommended next actions.

It does not certify that runtime or Git state is still current. The fresh conversation must re-inspect live Herdr/Git/runtime state before mutation.

Handoff#

Handoff is useful at a natural work boundary before the current conversation becomes difficult to manage. It has one product action in the in-page HUD; the Side Panel does not duplicate it. The same canonical package also supports WebChat self-handoff and a user copying the prompt into a newly opened conversation.

It is supported for bound ChatGPT Project conversations and stable z.ai /c/<chat_id> conversations. Handoff can start with Auto on or off; the target conversation inherits the source Auto state. Automatic wakes from the source pause while the transfer is active. For ChatGPT, cutover changes only the Project binding's active conversation target; for z.ai it migrates the conversation-scoped binding. The workspace must not have active working agents, so settled/wake delivery cannot race the cutover.

For ChatGPT, Rust first resolves the durable Continuity Journal and calls the read-only herdr_mcp.browser_handoff.prepare. The returned package contains the existing continuity_id, exact source_url, optional work_chain_id, minimal target context, and one compact message. automatic_delivery.params.message and manual_delivery.copy_prompt are byte-for-byte the same message. Automatic delivery passes it unchanged to browser_session.create; the new conversation begins by calling continuity.resume and then re-checks live workspace / Git / runtime state. If browser control is confirmed unavailable, the HUD exposes Copy Prompt from that already-prepared package. A seed_uncertain / uncertain mutation outcome does not expose Copy Prompt until reconciliation proves the first delivery did not apply, so Herdr cannot create a second conversation by guessing. If automatic delivery returns no Herdr execution or result fields, that outcome provides no evidence that workstation execution occurred; use the already-prepared Copy Prompt or re-observe the exact dispatch when one exists. Herdr-reported uncertain delivery remains reconciliation-only and is never replayed automatically. Existing provider-specific legacy transfers keep their compatibility recovery contract, but new durable ChatGPT handoffs have no second prompt builder.

z.ai summary/seed control messages use a raw channel so they are not wrapped again as JSON→MCP coding tasks.

Why Auto defaults off#

Continuity can actively submit messages, handle some page actions and change conversation identity. New scopes therefore default to Auto off.

The intended progression is: observe first, then automate.

Validate continuity with a real task#

A meaningful UAT should verify:

the intended browser scope is bound to the intended workspace; for ChatGPT Projects, verify the stable Project binding and its active conversation target separately;
Auto is enabled for the right scope;
a real agent task enters working;
new output produces a progress wake without spam;
workspace settle wakes the Web planner;
reload/browser restart preserves the correct binding;
an explicit handoff changes the ChatGPT Project active target only after the new seed is verified (or migrates the binding after confirmation on conversation-scoped sites); a confirmed delivery failure exposes the same canonical Copy Prompt, while an uncertain delivery does not.

Implementation history belongs in CHANGELOG. This page describes current behavior.