LocalEndpoint Connect Guide

Full report

On this page

A safe front door for local AI, with real control staying on your Windows machine.

LocalEndpoint Connect is best understood as a Windows desktop companion for local-first AI workflows. The current LocalEndpoint homepage says the website explains the path, while LocalEndpoint Connect is the Windows app “where local approval happens,” and the site’s platform accounting draws a hard line between the public website as the trust and evidence surface and the desktop app as the local authority surface. Current release metadata lists Desktop 0.2.154.0, release name Nontechnical Start Expert Options, with a UTC release timestamp of 2026-07-04T03:49:36Z, distributed as a checksum-backed invited-test ZIP rather than a marketplace-style general-public installer.

There is one important nuance in the public record: the site also preserves older boundary pages from an earlier package generation that describe Connect as “planned / not live.” Those older records are still useful because they state the trust boundary in unusually direct language: no localhost fetch, no filesystem read, no command execution, no tunnel, no live MCP relay, and no automatic decision. Read together, the current site behaves like a guide, download, validation, evidence, and handoff surface, while the older pages remain boundary evidence explaining what the public web must not do.

What the website can do

LocalEndpoint.com can explain the product, publish trust-boundary language, present the current desktop artifact, serve checksums and release metadata, expose machine-readable route indexes and OpenAPI-style metadata, and run browser-local validation helpers for public-safe manifests and receipts. The platform accounting page says the public site owns explanation, validation, documentation, release information, and redacted evidence, while the architecture page says visitors should be able to see the lane change clearly: public discovery explains, browser validation checks shape, evidence records the review, and desktop approval happens on the device.

For a new visitor, Start Here is the right first stop. The homepage explicitly says “Start here when you want to understand, try, or verify LocalEndpoint,” and it presents three safe next steps: understand it first, download the Windows app, or validate a manifest in the browser. It also says, in plain language, that nothing on the website runs AI or controls your computer. The plain-language start guide reinforces the same idea by presenting the website as a “public map” rather than runtime access.

The website can also act as a handoff surface. The public demo-handoff copy says the site may describe a safe preview handoff for the installed desktop app, where the app opens a local Request Room for review. Just as importantly, the same page says the handoff copy does not connect to localhost, read files, open a tunnel, execute commands, call MCP tools, or transmit data, and that demo URI examples on the public site are text-only metadata rather than clickable activation controls. That means the website can introduce a review request, but the website itself still does not become a control channel.

If the desktop app is not present, the website’s safe job is to send the visitor to the download path, not to “do it in the browser instead.” The download page says there is one checksum-backed desktop ZIP for invited smoke testing, and it tells visitors to download the ZIP and manifest, match the SHA-256 sidecar, and then review things locally.

What only the desktop app can do

The desktop app is the only place where private, meaningful local work can happen. The platform accounting page says the desktop app alone owns package loading, local prompt assembly, model intake, model execution, approval, registry, audit, and JSONL event ownership. It is also the only place that imports, validates, expands, and loads .uaix packages and their .uai memory files; assembles prompts from approved local memory and user-selected context; and verifies model artifacts, sidecars, hashes, byte counts, hardware fit, active registry rows, and session identity before runtime allocation.

That desktop-only boundary is the right way to explain interfaces such as an Approval Queue or Action Queue from a visitor’s point of view. The current public pages consistently place local approval, command review, receipts, and exported local review evidence inside the app, not the website. The download page says “command review, and approval stay in the app,” while the demo-handoff copy says the installed app may open a local Request Room where a person can review a mock request, add notes, draft a clarification, snooze, approve a mock grant, deny the request, and export local review evidence. In other words, whatever the current desktop UI label is, the underlying concept is the same: review first, approve locally, keep evidence local, and do not let the website decide for you.

The Models area is also desktop-local. LocalEndpoint’s model-lifecycle documentation says a downloaded model is not usable just because it exists on disk. Desktop review has to verify the model format, license sidecar, inventory sidecar, SHA-256, byte count, revision, hardware fit, and selected model identity before activation. The same documentation says ready candidates show owner-approved local download options, blocked candidates show the required next action instead, and runtime remains gated behind readiness checks for prompt text, .uaix package memory, persona.uai, Documents-backed wiki roots, download, activation, runtime, and worker readiness.

The Chat experience, as far as the current public record confirms, is also desktop-local. LocalEndpoint’s runtime documentation says the bounded GGUF runtime is called only after LocalEndpoint has prepared and approved a display-safe local request context, and the model-lifecycle docs say worker allocation, prompt tokenization, inference, and token streaming all stay behind local desktop gates. Those same pages also say provider APIs can remain disabled, prompt and generated text do not live in persisted audit/public evidence, and the runtime does not own policies, registry, audit, telemetry, or network access.

The public documentation is very strong on local execution, readiness gating, token streaming evidence, privacy boundaries, and no-provider requirements. It is not equally explicit, on the live pages I could verify, about every chat-control label a visitor might see in the desktop UI, such as a named structured-output validator, a specific cancellation button, or exact sampling-control labels. The safest accurate way to explain that is: Chat is clearly documented as a local, approved, bounded GGUF workflow, while fine-grained chat controls should be presented as desktop-interface details rather than promises made by the public website.

The Files and Memory story is also clearly local. The platform accounting page says .uaix packages expand into .uai memory files and local wiki memory roots, with Documents-backed folders as the default long-term wiki roots, and it explicitly says .uaix or .uai memory cannot grant hosted inference, provider APIs, telemetry, shell execution, command execution, automatic export, network access, or core safety-policy override by themselves. That is the plain-language visitor takeaway: files and memory are registered and loaded locally by the app; they are not uploaded to LocalEndpoint.com for the website to inspect.

The same desktop-only rule applies to audit, governance, and diagnostics. The platform accounting and runtime pages say audit persistence and JSONL event ownership belong to LocalEndpoint Desktop, while prompt text and generated text are intentionally kept out of persisted public evidence. The runtime docs also describe diagnostics and proof receipts as display-safe evidence and explicitly say diagnostic GPU records are not the same thing as proven GPU inference. In public evidence, LocalEndpoint already uses UTC-style timestamps such as releaseDateUtc and generated_at_utc; that makes it reasonable to describe local audit evidence as following the same time-discipline, while still being owned by the desktop app rather than the website.

<details> <summary>Expert notes on GGUF, .uaix, sidecars, receipts, and evidence packets</summary>

LocalEndpoint’s current public docs use these terms in a specific way. GGUF is the local model format the bounded runtime executes after approval. .uaix is a portable package that Desktop expands into .uai memory files and local wiki roots. Sidecars are companion evidence files such as license and inventory records that help prove a model is the reviewed artifact you think it is. Receipts and evidence packets are review artifacts that travel forward without carrying raw prompts, generated text, credentials, or private endpoint payloads. </details>

What never happens automatically

The public website does not execute desktop commands. Multiple current pages say the website does not dispatch desktop commands or become a hidden runtime bridge, and the homepage says plainly that nothing on the website runs AI or controls your computer.

The website does not read local files, probe localhost, or scan private networks. The current homepage and documentation say “no localhost probing,” and older but still-public boundary pages add “no filesystem read” and “no private-network scanning.” The architecture page reinforces that private runtime, credentials, secrets, and device state stay outside the public gateway.

The website does not open tunnels or establish live MCP connections. The local runtime safety model says there is no tunnel startup or live MCP execution, while the older Connect pages say no tunnel and no MCP relay are active in those public packages.

The website does not upload prompts, files, models, generated text, credentials, or telemetry. The current homepage and docs say there is no upload intake, no prompt intake, no telemetry, and no credential collection, and the model/runtime pages add that registry, audit, and public evidence remain free of prompt and generated text content. I did not find a current fetched page that separately lists desktop data types such as window titles or process paths by name, so the safest accurate visitor wording is that the public site does not collect private desktop state and keeps meaningful local evidence on the device.

Nothing meaningful runs automatically inside the desktop app either. The model-lifecycle docs say the Run Local workflow cannot execute while readiness is blocked, and even direct command invocation is documented to fail closed by returning a display-safe readiness blocker instead of starting work. LocalChatViabilityEvidence is created before a worker envelope exists, and non-viable state becomes a blocked no-op before allocation, tokenization, or inference.

Beginner walkthrough

1. Start on LocalEndpoint.com and read the homepage or plain-language start guide first. Those pages are the clearest explanation of what the website is allowed to do and what it deliberately does not do.

1. If the desktop app is not installed, open the download page rather than looking for a browser-based fallback. The public flow is download the desktop ZIP, check the SHA-256, and review locally.

1. If the site presents a safe demo handoff or demo-request page, treat it as a preview-only handoff. A user-supplied example pattern like the following is consistent with the public handoff concept, but the verified site language says public demo URI examples are metadata-only and do not themselves connect to localhost, call tools, or start commands:

   localendpoint-connect://preview/request?scenario=localhost-health-check

1. Confirm that the installed desktop app opens a review surface rather than “doing something” in the background. The public handoff copy says the app may open a local Request Room where a person reviews the request, adds notes, drafts clarification, snoozes, approves, denies, and exports local review evidence.

1. Inside the desktop app, begin with Start Here. The current release materials emphasize a “Nontechnical Start Expert Options” path, and the public route index summary says installed-app smoke checks included Start Here beginner and expert option checks.

1. Try a safe preview or first-run path before adding models or memory. The current public docs show a first-run guide, a readiness card, and a compact checklist intended to show the next required action without scraping raw metadata or launching a blocked workflow.

1. Visit the desktop review surface next. If the app calls it Approval Queue, Action Queue, or Request Room, the documented behavior is the same: review proposed local work first, inspect the explanation, and keep the receipt local.

1. Visit Models before downloading anything. The public docs say the app can browse Hugging Face metadata, filter local-download-ready GGUF candidates, and show whether a candidate is ready or blocked, including hardware-fit and sidecar evidence.

1. Only after you understand the local-only boundary should you move into memory packages, advanced routes, runtime-readiness checks, or expert diagnostics. The website itself frames advanced inspection as a later step, not the first-screen experience.

Advanced explorer walkthrough

For an expert review, the website’s Advanced options are the right public entry point. The homepage currently exposes the release manifest, SHA-256 inventory, platform accounting, route index JSON, OpenAPI metadata, and quality-gate status. Those pages let you inspect what is being claimed without turning the site into a runtime surface.

The architecture page is especially useful because it makes the trust-boundary sequence explicit: public discovery, browser validation, evidence export, desktop approval, and then private runtime. That is the cleanest way to explain why the website can help someone understand or verify a workflow, while the Windows app remains the only place where local approval and execution can actually occur.

For models and memory, the most important expert pages are Current Platform Accounting, Local Model Lifecycle, and UAIX.LmRuntime Integration. Together they document local-ready GGUF browsing, owner-approved local download staging, sidecar and hash verification, hardware-fit checks, .uaix expansion into .uai memory, Documents-backed wiki roots, the active model registry, and the bounded runtime handoff that remains blocked until approval and readiness gates pass.

For diagnostics, the public docs support a conservative framing: diagnostics are display-safe review material for experts, not proof that the website scanned or controlled anything. The runtime docs repeatedly distinguish diagnostic GPU evidence from actual GPU inference, and the quality-gates record explicitly says public review signals do not certify deployment success, runtime safety, or security compliance.

A few desktop-oriented labels in your brief, such as Approval Queue, Action Queue, Self-Check, and Developer Mode, fit the documented product pattern, but I could not verify each of those labels as a fetched standalone current public page in this research session. What I could verify is the underlying behavior the website already supports publicly: Start Here for beginners, advanced options for experts, local approval and command review in the app, installed-app smoke evidence, exported review evidence, and a public route explorer that keeps advanced machine-readable material available without making it the first-screen experience for beginners.

<details> <summary>Expert notes on archival boundary pages and current release records</summary>

The live site currently contains both a newer desktop-download/accounting surface and older boundary/planning pages. The newer surface is the strongest source for the current tester package, the Windows ZIP, and the local-model/runtime workflow. The older surface is still valuable because it states durable non-claims very clearly: no tunnel, no localhost access, no MCP relay, no command execution, no automatic decisions, and no public-site runtime authority. Taken together, they form a stricter not-looser reading of the trust boundary. </details>

Capability map and troubleshooting

What the website can do: explain the product, show the current desktop artifact, publish checksums and manifests, run browser-local validation for public-safe metadata, expose machine-readable evidence, and describe safe preview handoffs.

What only the desktop app can do: load .uaix packages, expand .uai memory, assemble prompts, review models, verify sidecars and hashes, select an active model, create local approval decisions, persist audit and JSONL evidence, and run local GGUF inference after readiness gates pass.

What never happens automatically: public-site localhost probing, file reads, tunnel startup, live MCP execution, public prompt intake, public command dispatch, credential collection, telemetry collection, or website-side model execution. Even inside the app, blocked readiness stays blocked until a person reviews and approves the next step.

App not installed

Open the download page, download the current desktop ZIP, match the SHA-256 sidecar, and review the release manifest before you proceed. The public download posture is explicitly checksum-backed invited use, not a “click and we’ll run it for you” browser flow.

Handoff did not open

Treat that as a safety event, not a failure of hidden automation. The public demo-handoff page says the site’s demo URI examples are text-only metadata and not clickable activation controls, so a public page may explain the handoff concept without actually triggering it. If nothing opened, go through the desktop app’s Start Here path and local review surfaces instead of assuming the website should retry against localhost.

I do not know what to click next

Go back to Start Here on the homepage or the desktop first-run guide. The public docs show a first-run checklist, a compact readiness summary, and a single next-action pattern designed specifically so a new user can see one candidate decision and one next action without reading raw metadata or expert-level diagnostics first.

Final reminder

The most important thing to understand about LocalEndpoint Connect is that the user stays in control. LocalEndpoint.com can inform, validate, publish evidence, and hand off a preview; the browser can inspect public-safe structure; the desktop app is where approval happens; and private runtime stays on the user’s own machine. Every meaningful local action is supposed to be reviewable, locally approved, and backed by receipts or evidence rather than hidden web behavior.