What is the Neural Link?

The Neural Link is a bi-directional bridge that connects AI agents directly to the Neo.mjs runtime. It lets agents inspect the Scene Graph, component state, event listeners, computed styles, and DOM rectangles, and mutate the running application in real time.

Why is Neo.mjs called an Application Engine instead of a framework?

Neo.mjs maintains persistent application objects in a worker-backed Scene Graph instead of compiling application state away into ephemeral DOM nodes. That architecture enables multi-window orchestration, runtime permutation, and deep AI introspection.

What is Context Engineering?

Context Engineering shapes the information and tool environment around AI agents. Neo.mjs implements it through Knowledge Base, Memory Core, GitHub Workflow, and Neural Link MCP servers for frontier harnesses, plus a File System MCP server for internal Neo.ai.Agent local loops.

What is the Neo.mjs Agent OS?

The Neo.mjs Agent OS is the repository Brain: source code and services for Memory Core, Knowledge Base, Active Hybrid GraphRAG, DreamService, Golden Path synthesis, A2A coordination, and Neural Link tooling.

Frontmatter

id	12380
title	[neo] Canonical cloud-deployment client-auth docs — GitLab-PAT Bearer login recipes (Sub of #12377)
state	Closed
labels	enhancementai
assignees	neo-opus-ada
createdAt	Jun 2, 2026, 2:02 PM
updatedAt	Jun 7, 2026, 7:18 PM
githubUrl	https://github.com/neomjs/neo/issues/12380
author	neo-opus-ada
commentsCount	0
parentIssue	12377
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	Jun 2, 2026, 5:36 PM

[neo] Canonical cloud-deployment client-auth docs — GitLab-PAT Bearer login recipes (Sub of #12377)

Closed v13.0.0/archive-v13-0-0-chunk-15 enhancementai

neo-opus-ada commented on Jun 2, 2026, 2:02 PM

Sub of #12377. Owner: @neo-opus-ada. Folds into the Track-1 cloud-deployment docs hardening.

Goal

Document, in learn/agentos/cloud-deployment/, how real users and headless agents authenticate to a deployed MCP server with a GitLab PAT Bearer token — no cookie, no browser OAuth dance.

Scope

The auth model: GitLab PAT (scope read_user) → env var → Authorization: Bearer <PAT>; server validates against GitLab /api/v4/user; naked 401 (no OAuth PRM).
Client recipes: mcp-remote (--header "Authorization:Bearer ${TOKEN}"), Claude Code (claude mcp add --transport http + header), MCP Inspector (per sub "Inspector v0.21.2 compat" verdict).
Where the token lives (env var, e.g. .zshenv); how to mint a read_user PAT.
The "test profile vs prod auth profile" distinction.

Acceptance Criteria

A first-time deployer can follow the doc to get a user/agent authenticated with a PAT.
Client recipes for mcp-remote + Claude Code (+ Inspector per sub-2's outcome) are copy-paste.
No client/customer names; generic capability framing.

Depends on sub "GitLab-PAT Bearer auth mode" + sub "Inspector v0.21.2 compat" (#12377).

tobiu referenced in commit 50b9034 - "docs(ai): cloud-deployment GitLab-PAT client-auth guide (#12380) (#12385) on Jun 2, 2026, 5:36 PM

tobiu closed this issue on Jun 2, 2026, 5:36 PM