Approval gates, local audit trail and resumable runs in Aiglade: what actually exists

Last updated: 2026-10-25

Aiglade is a Windows desktop app that puts Claude Code, Codex CLI, Hermes and OpenClaw into one window, with a Chinese onboarding wizard, ready to use without knowing how to program. Approval gates, a local audit trail, and resumable runs describe how work is controlled, recorded, and continued inside that single window. An approval gate is a point in a run where a gated operation pauses for user confirmation instead of proceeding on its own. The audit trail has two legs: state changes go to an audit table in the store, and session records stay in files on the local disk; a resumable run means that a task marked resumable with a checkpoint can be continued from its breakpoint.

This page explains each of the three items separately and in plain terms. It does not describe any other control, record, or recovery mechanism. The description stays close to what the product provides in its Windows desktop form, where the desktop window is the only console and there is no web version. The built-in agents named here are Claude Code, Codex CLI, Hermes, and OpenClaw. The Aiglade about page is the main source for the product description, and the sections below keep the three items apart so that a reader can see what each one does and what it does not claim to do.

What does an approval gate do in Aiglade?

An approval gate is a runtime confirmation point. When a task enters a state awaiting approval, the server attaches a gate carrying a gate id, node id, trigger type, reason, retry count, status, timeout in seconds, and pending-since time, and the operation pauses. The user sees a confirmation card with two actions, approve or reject, handled through POST /gates/:gateId/respond. Approval is decided by object equality, not by keyword matching, and a gate carries a timeout: a timeout is not a default approval. The pause is part of the run itself, not a separate stage added after the run has finished, and the risky operation does not proceed while it is waiting.

The value of the gate is in its timing. A run can proceed through ordinary work without interruption, and it stops only when it reaches an operation that triggers a gate. The confirmation point is therefore tied to the operation and to the state of the run at that time. A reader who wants to understand the tools behind the window can consult the Claude Code documentation and the Codex documentation for the separate tools that run inside the window. Those documents describe their own tools, and they do not change the description of the gate itself, which is a pause for user confirmation at runtime.

The gate also shapes how a run should be understood by someone who is watching it. A paused run is not a failed run and it is not a finished run. It is a run that is waiting for a human decision at a defined point. The record of the run, discussed below, reflects that waiting state in the same way that it reflects other states of the run. The gate does not remove the need for the user to pay attention to the run, and it does not make the run independent of the user. It makes the dependence explicit at the point where a gated operation would otherwise proceed without a check.

When does Aiglade pause for user confirmation?

Aiglade pauses only when an operation triggers a gate. It is not true that every operation requires approval: only a gated operation pauses, and operations that do not trigger a gate are outside the scope of this page. The pause happens at the runtime confirmation point for that operation, and the operation remains paused until the user approves or rejects it. The confirmation is therefore a condition for continuation, not a note added to the run after the operation has already happened. If the user does not confirm, the gated operation does not proceed on the basis of the gate alone. This is the whole of the approval behaviour described here, and it is stated in these terms on purpose, so that the reader does not infer a broader approval system from the presence of a single confirmation point.

The pause is also local to the run and to the desktop window. The user confirms in the same window where the run is taking place, and the run continues in that window after confirmation. There is no separate console for approval, because the desktop application is the only console. The same window that hosts Claude Code, Codex CLI, Hermes, and OpenClaw is the window where the confirmation is given. That single-window structure matters for understanding the gate, because it means that approval is not handled by a different product or by a different interface. It is handled where the work is happening, at the time when the gated operation is reached.

A reader who is used to reading vendor documentation may find it useful to compare how different documents present tool behaviour. The OpenAI platform documentation and the Google AI developer documentation are examples of separate vendor documentation for agent and model tooling, and they show how tool behaviour is normally documented by its own provider. The Aiglade homepage presents Aiglade itself as a Windows desktop application. The gate described here should be read against that product description, not against a general expectation about approval systems in other products.

Where does the audit trail live?

The audit trail lives in two places, and the two places answer different questions. The first leg is state-change auditing: the daemon writes every state change through one audit call into the sh_activity audit table in the store, with actions covering create, dispatch, heartbeat, status change, gate, resolve, and archive. That record lives in the store, not as a plain-text file on disk. The second leg is session records: each CLI keeps its own session records in files on the local disk, Claude Code under ~/.claude/projects/…/*.jsonl and OpenClaw under ~/.openclaw/agents/<agent>/sessions/. Those files are local. A reader who checks a record should know which leg they are looking at, because the audit table answers what state changes happened, while the session files answer what each CLI session itself recorded.

Where do session records live on disk?

Session records live in files on the local disk, one set per CLI. Claude Code session records sit under ~/.claude/projects/…/*.jsonl, and OpenClaw session records sit under ~/.openclaw/agents/<agent>/sessions/. Checking a session means opening the file for that CLI and reading what it recorded, not querying a single combined log. The two legs together give a reader two ways to check the same underlying work, one through the audit table in the store and one through the session files on disk. Neither leg is presented here as a substitute for the other, and neither is presented as a separate reporting product.

Chinese developer documentation also discusses tooling, records, and configuration for agent and model work, and it provides a useful reference for readers who work in a Chinese-language documentation environment. The Alibaba Cloud Model Studio documentation and the Zhipu open platform documentation are examples of that documentation, and the DeepSeek API documentation is another example of a Chinese provider document for model tooling. Microsoft Learn is a further example of vendor documentation that explains tooling and configuration in a structured form. These sources are cited here as documentation reference, not as sources for Aiglade behaviour, and the description of the Aiglade audit trail remains the description given above.

Which interrupted tasks can resume, and which cannot?

Only a task that is marked resumable and carries a checkpoint can resume. It is not true that any interrupted task can be continued from its breakpoint. After the daemon crashes or restarts, orphaned tasks are marked resumable and keep their checkpoint data, and resumption is started manually: the checkpoint is read, the task moves from resumable back to running, and history is injected for the rerun. A task in any other state cannot resume and gets a 409 response, and the search runtime does not support resumption at all. This conditional scope is the whole of the resumable behaviour described here, and it is stated in these terms on purpose, so that the reader does not infer a general promise that every interruption ends in a clean continuation.

Resumable execution also depends on the local character of the product. Because the audit table and the session files preserve what the task did, the task that resumes is the task whose record is already in the store and on that machine. The user who resumes the task is working in the same window, on the same machine, with the same records that stored the task. The checkpoint is meaningful because the preserved task is continued from that checkpoint, rather than starting from an empty state.

How do approval, local records, and resumable runs work together in a single run?

In a single run, the three items describe three different moments of control, record, and continuation. Approval describes the moment when a gated operation pauses for user confirmation on a confirmation card, and the run waits at that runtime confirmation point until the user approves or rejects it. The record describes two legs: state changes written to the audit table in the store, and session records kept in files on the local disk. Resumable execution describes the moment after an interruption, when a task marked resumable with a checkpoint can be continued from that checkpoint after a daemon crash or restart.

The three moments do not overlap in function, and they should not be merged into a single claim. A pause for confirmation does not by itself create a record, and a record does not by itself resume a task. A resumed task still pauses at a gated operation when it reaches one, because the gate applies to the run as it continues, not only to the run as it first started. A checked record still reflects the pause and the resumption, because the record is the account of what the run did, where it waited, and where it continued. The three items therefore fit together as a sequence that a reader can follow through a run, from control at a gated step, through a checkable record in two legs, to conditional continuation after an interruption.

A reader who follows that sequence will have a clear picture of what exists and what does not need to be assumed. The desktop window is the only console, the built-in agents are Claude Code, Codex CLI, Hermes, and OpenClaw, and the onboarding wizard is Chinese. The gate is a pause for user confirmation at runtime for a gated operation. State changes go to the audit table in the store, and session records stay in files on the local disk. Only a task marked resumable with a checkpoint can be continued from its breakpoint, and the search runtime does not support resumption. That is the full scope of the three items as described here, stated in plain terms and without additional claims.