CLI Realtime Feedback & Autopilot

When you use HENGSHI CLI, an Agent, or a script to change resources outside the browser, the key question is usually not “did the command succeed,” but:

when should that change show up on the page I am looking at?

Autopilot is the UI-side status indicator for that “CLI / Agent change → browser feedback” loop. This page focuses on three things:

1. what Autopilot helps you judge
2. which scenarios are good candidates for realtime feedback
3. which scenarios still rely mainly on synchronous execution or polling

Why a CLI guide needs an Autopilot page

HENGSHI CLI is the out-of-browser execution surface. Autopilot is the in-browser realtime connection indicator. Together they form the full delivery loop:

CLI / Agent / Script
→ backend accepts the change
→ SSE pushes related resource updates
→ the current page receives them
→ Autopilot shows whether the connection is still alive

That is why Autopilot is more than “a small status element in the header.” It helps you answer:

• is the current page still receiving realtime updates?
• does the out-of-browser change have a chance to flow back into this page?
• if nothing changed, is this more likely a connection issue, a scope issue, or a local-state protection issue?

What Autopilot is — and what it is not

What it is

The Autopilot indicator is a small realtime connection status element shown at the top of the page. It tells you whether the current page is still receiving live updates from the system.

Technically, this capability is built on SSE (Server-Sent Events), but in daily use the main thing you usually need is the on-page connection state.

What it is not

Autopilot is useful, but it does not mean any of the following:

• not every page will auto-refresh
• not every backend action will immediately repaint the current page
• not the execution status itself — it shows connection health, not task status, logs, or history
• not a forced overwrite of local edits — pages with unsaved local work may intentionally avoid applying outside changes directly

The SSE system switch and Autopilot visibility

Administrators can control whether the instance exposes SSE realtime delivery through the GENERAL_CONFIG_ENABLE_SSE system environment key. The default is enabled. In frontend system preferences, this value is exposed as the enableSse field.

That switch directly affects whether the frontend starts the SSE transport and whether the Autopilot UI is visible:

• When enabled: supported desktop pages establish the /api/sse/subscribe realtime connection and show the Autopilot indicator where the page boundary allows it
• When disabled: the frontend does not start the SSE transport, the Autopilot indicator is hidden, and you should no longer expect realtime feedback through this path

Everything described in this public Autopilot / realtime-feedback guide assumes that GENERAL_CONFIG_ENABLE_SSE is still enabled for the current instance.

This switch controls the SSE / Autopilot feedback path. It is not the same thing as overall ChatBI / Agent availability, and it does not mean every page will auto-refresh.

Where realtime feedback is most reasonable to expect

For public product documentation, the most important surfaces to emphasize here are really dashboard and report pages, especially view and edit pages.

For most CLI + Agent delivery scenarios, what people usually care about is not whether a generic list refreshed, but whether the authored result is now visible on the current dashboard or report page.

Typical examples include:

• CLI or an Agent creates or updates a dashboard / report
• chart, filter, text, button, image, or container changes are authored outside the browser
• a dashboard plan is applied and you want to confirm that the current canvas reflects it

List pages and other detail pages such as Notebook / Pipeline are still covered by the same mechanism, but they are better treated as supporting scenarios. In day-to-day delivery, the highest-value Autopilot use case is still dashboard/report feedback.

Scenario	What it is good for	Typical examples
Dashboard / report view and edit pages	reflecting out-of-browser creation or updates back into the current canvas or current page	dashboard plan apply, chart/filter/text/container changes, report page updates
List pages	reflecting out-of-browser create / delete / update back into the current list	app lists, scientist lists, pipeline lists
Other detail pages	reflecting structural changes back into the currently open resource detail page	notebook paragraph changes, pipeline node add/remove/update

In practice, Autopilot is most useful when you need to confirm:

1. the currently open dashboard / report page is the actual target of the outside change
2. the current page and the external change refer to the same resource
3. the page is one of the surfaces that actually supports realtime feedback
4. the underlying connection is still alive

Current page boundary

The table below separates two different questions:

• whether the Autopilot indicator is expected to appear
• whether the page has a clearly integrated resource-level realtime refresh path

Those two things are not always the same. Seeing the indicator does not automatically mean that the current page already supports realtime refresh for the resource you changed.

Also note that this table assumes the instance-level GENERAL_CONFIG_ENABLE_SSE switch has not been turned off. If SSE is disabled for the instance, these surfaces stop showing the Autopilot indicator as well.

Page type	Autopilot indicator	Clearly integrated refresh today	Notes
Standard desktop pages with the main header	Supported	Depends on whether that page has realtime refresh integrated	Typical examples include app/folder lists, dataset lists, dashboard lists, Scientist lists, and Pipeline lists
Dashboard / report view and edit pages with their own header	Supported	Dashboard resource refresh is integrated	This is the primary delivery scenario today; publish, share, preview, and embedded-container modes are outside this layer
Scientist Notebook detail page	Depends on the page shell header	Notebook resource refresh is integrated	If local paragraph edits are still unsaved, outside changes are queued instead of being applied immediately
Pipeline detail page	Depends on the page shell header	Pipeline resource refresh is integrated	Node add/remove/update is covered; unsaved graph edits also queue outside changes
Top-level Kanban page	Outside the current standalone toolbar-indicator scope	Kanban resource refresh is integrated	Draft, analysis, share, ChatBI, and screenshot variants are outside the current subscription boundary
Execution record / DAG / log surfaces	The indicator may still be visible	Do not treat them as SSE-first	These pages currently rely more on synchronous waiting or polling
Mobile / floating surfaces	Not guaranteed	Should not be assumed	Mobile hides the indicator; Kanban, measure, and ChatBI floating surfaces are outside the current standalone toolbar-indicator scope

If we make the scope even more concrete, the pages that can be clearly listed in this boundary as of the current version include at least:

• app / folder lists, including app, public, and datamart root and folder routes
• dataset lists
• dashboard / page / report lists
• Scientist lists
• Scientist Notebook detail
• Pipeline lists
• Pipeline detail
• dashboard / report view and edit pages

The point of this table is not to promise that every one of these pages will “refresh everything automatically.” It is to help you answer a simpler question first: is the current page even inside the known Autopilot / realtime-feedback boundary?

Where you should not treat it as the primary mechanism

Even if Autopilot is visible, the following scenarios should not be treated as “SSE-first.”

1. Execution actions

Using pipeline execution as an example, the “Run now” action on the detail page behaves more like a synchronous execution path: the frontend waits for the backend to return the status for that run instead of just firing once and depending entirely on SSE.

That means:

• first judge the execution by the execution result itself
• do not treat the lack of an immediate push as proof that execution failed

2. Execution records, DAG, and log surfaces

These pages are currently more likely to use polling than to use Autopilot as their main refresh path.

For example:

• execution record pages
• DAG pages
• some log / history views

Those pages may still update, but the update is more likely to come from synchronous waiting or polling than from the same kind of direct resource feedback used on detail pages.

3. Pages with unsaved local edits

If the current page already contains unsaved local work, outside changes may intentionally avoid overwriting it.

That is a protection mechanism, not necessarily a realtime failure. In this case, first distinguish:

• whether the page is intentionally protecting a local draft
• or whether the connection itself is actually broken

Common states

Common Autopilot states include:

State	Meaning
Autopilot connecting	The page is establishing the live connection
Autopilot connected	The page can receive realtime updates
Autopilot reconnecting	The connection dropped and is being restored
Autopilot disconnected	No usable connection is available and the page may be stale

When the indicator is disconnected, the page usually exposes a retry path.

Recommended validation order

When you are checking whether a CLI / Agent change has made it back into the UI, use this order:

1. Check whether the command itself really succeeded
   • start from CLI output, structured result, and errors
   • do not begin from the browser alone
2. Check whether the current page is the right resource context
   • does the current list or detail page actually cover the resource you just changed?
3. Check whether Autopilot is connected
   • if the connection is already down, a stale page is expected
4. Distinguish resource mutation from execution flow
   • resource mutations are better candidates for realtime feedback
   • execution flow, records, and DAG are more often synchronous or polling-driven
5. Only then decide whether the issue is connection, scope, or local draft protection

This usually gets you to the answer faster than assuming the UI is wrong as soon as a command succeeds.

Environment and proxy requirements

If your instance sits behind Nginx, Ingress, TongWeb, or another reverse proxy, pay special attention to /api/sse/subscribe. The most common failures are not business-logic bugs, but long-lived connections being cut too early or buffered until they stop being realtime.

At minimum, the SSE path should:

• allow long-lived connections
• disable response / proxy buffering
• avoid caching SSE responses
• use sufficiently long read / send timeouts

A typical Nginx reverse proxy setup looks like this:

location /api/sse/subscribe {
  proxy_http_version 1.1;
  proxy_set_header Connection "";
  proxy_buffering off;
  proxy_cache off;
  proxy_read_timeout 3600s;
  proxy_send_timeout 3600s;
}

If you use ingress-nginx, TongWeb, or another gateway, make sure the equivalent behavior is configured: long-lived connections, buffering disabled, and relaxed timeouts.

The proxy layer is often the first thing to check when:

• Autopilot stays in reconnecting or disconnects frequently
• CLI succeeds but the page never receives any live feedback
• realtime sync works on direct access but disappears behind the gateway

Example

The image below shows the Autopilot indicator in the top header of the local Application Mart example:

One-line takeaway

If you only want to remember one sentence, make it this:

Autopilot tells you whether the realtime connection is alive; it does not guarantee that every page will refresh everything automatically.

If you want to continue debugging why a change did not appear on the page, go straight to Troubleshooting & FAQ.