Skip to content

Releases: valteresj2/agent-hangar

v0.53.0 — the Hangar desktop app connected to the platform

Choose a tag to compare

@valteresj2 valteresj2 released this 25 Oct 20:18

The Hangar desktop app now connects to Agent Hangar: people sign in with their company account, run sessions on the token models the admins sync, and see their workspace with live updates. Guide: docs/desktop-app.md.

Added

  • Sign-in and devices. OAuth from the app (loopback redirect on any port), grants with scopes (app, mcp; clients that ask for none keep mcp, so Claude.ai and ChatGPT are unaffected), device registration and heartbeat, and a new App Hangar hub in the console (overview, Windows policy, versions in use, devices with revoke). Migration 0052.
  • Token models synced to the desktop. Turn on Sync token models with Hangar desktop on an Anthropic-protocol LLM connection; each person picks, per session, between their Claude subscription and those models. Calls go through the central’s LLM proxy with a device-bound key: the provider key stays in the vault, hidden models, the code policy and budgets are enforced, and usage records tokens and cost without logging content. Migration 0053.
  • The member’s workspace in the desktop. The app’s token works on an explicit allowlist of member routes, always with the person’s own access, and GET /api/app/events streams inbox, decision, agent-status and model-list events over SSE. Migration 0054; reverse proxies need buffering off and a 60 s read timeout on that route.
  • Hangar AI Labs website with the documentation under /docs/.

Security

  • The LLM proxy read the request body before checking the device key; the key is now checked first and the body is cut at 32 MB while it is read.

Changed

  • Dependency floors raised (FastAPI 0.160 and uvicorn 0.54 in the runtime; uvicorn, SQLAlchemy 2.1.1, kubernetes, prometheus-client and the OTLP exporter in the central) and CI/release actions updated. The runtime’s mcp 2.x bump stays on hold.

Upgrading: back up the database first; migrations 0052–0054 run on startup.

VS Code extension: agent-hangar-0.53.0.vsix below.

Full list: CHANGELOG.md.

v0.52.0 — end-to-end sweep of the console and portal

Choose a tag to compare

@valteresj2 valteresj2 released this 23 Oct 21:39

An end-to-end sweep of the console and the portal: 283 pages visited by a browser robot (desktop, phone and in English), 148 API read endpoints called as an admin and as a member, the platform MCP’s read tools, and real clicks through the main actions. No 5xx anywhere; what it found is fixed here.

Fixed

  • Portal search didn’t find agents. It only looked for issues, Digital employees and tasks, so a person’s own agents and projects never showed up. It now searches agents, Digital employees, tasks, issues and projects.
  • Links to deleted tasks. O que aprendemos linked articles to source tasks that had been deleted with their team or Digital employee, and the link opened an error card. It now says “task removed”, and a task page that no longer exists explains that.
  • Pages wider than a phone screen. On a 375 px screen the agent page (Execution card), Meus agentes and Minhas issues scrolled sideways. Property lists now stack on small screens and long lines shrink.
  • Half-translated text in English. Whole sentences with numbers are now translated before loose words, so they no longer come out mixed. Also translated: the role in the Execution card, schedule descriptions (“every day at 09:00”), the issue key hint and the guide diagram’s tooltips. Issue descriptions, comments and template titles are data and are no longer partly translated.
  • Emergency session (admin token). The inbox and decisions pages now explain that they belong to a person instead of showing an error.
  • First platform-tools call took 4 seconds after each restart, which also delayed the first Digital employee task. The tools now load in the background at startup.

Added

  • Interface tests in CI. tests/e2e/ui_actions.py clicks through the console (save the spec, run tests, deploy to stage, Playground, schedule, execution profile, avatar) and the portal (create an issue from the board, comment, change status, search, switch language). tests/e2e/i18n_crawl.py now also fails when a page scrolls sideways on a phone, and covers the agent tabs and an issue with comments.

VS Code extension: agent-hangar-0.52.0.vsix attached.

v0.51.0 — Mem0 on pgvector as a memory backend (experimental)

Choose a tag to compare

@valteresj2 valteresj2 released this 23 Oct 01:23

Added

  • Mem0 on pgvector as a memory backend (experimental). MEMORY_BACKEND=mem0 with the memory-mem0 profile keeps agent memory as facts with vector search in PostgreSQL with pgvector, with no graph database. It can also use your company’s Postgres (MEM0_PG_URL: RDS, Cloud SQL and Azure Database all offer pgvector). Same tools, groups, stage isolation and Memory tab; local embeddings; Mem0 telemetry off.

Measured on the same install, with the same extraction LLM and the same facts:

Graphiti + Neo4j Mem0 + pgvector
Write 3 facts 149 s 10 s
Write one change 18 s 2 s
Search 40–70 ms 25–30 ms
Found “how many employees” No Yes
Plan changed from Pro to Enterprise Old fact marked as replaced, with the date Both facts stay current

Mem0 is much faster and cheaper to write and needs no graph database; Graphiti keeps the dated history of each fact. Graphiti stays the default. See docs/memory.md.

Upgrade: to try it, run scripts/setup.sh (or setup.ps1) again to generate MEM0_PG_PASSWORD, set MEMORY_BACKEND=mem0 and start the memory-mem0 profile.

VS Code extension: agent-hangar-0.51.0.vsix attached.

v0.50.0 — the GitHub MCP Registry as a connector source, and a documentation site

Choose a tag to compare

@valteresj2 valteresj2 released this 23 Oct 00:20

Added

  • Documentation site at https://valteresj2.github.io/agent-hangar/ (Astro Starlight): every guide in docs/, with sidebar sections, search, light and dark modes, and an overview page with a quick start. It is built from docs/ by the Docs site workflow on each change, and the interactive demo stays at /agent-hangar/demo/.
  • The GitHub MCP Registry is a connector source. The servers listed at github.com/mcp that aren’t already in the catalog appear in Conectores, each with the simplest way to connect it. Remote servers with OAuth (with dynamic client registration) or with no login connect in one click. Those that need a token, a header or an account address ask for exactly the fields the registry names. npm and PyPI packages with a pinned version run in the isolated runner, installed by an admin. The list is read in the background once a day (MCP_REGISTRY_URL, MCP_REGISTRY_TTL_S), and each server is probed with the same unauthenticated initialize call as Testar conexão, to public https addresses only. Servers that are down, OAuth without dynamic registration, and Docker-only or unpinned packages are left out. Each item shows the publisher, GitHub stars, license and repository. See docs/connectors.md.

Fixed

  • OAuth for remote MCP servers whose authorization server is on another domain (auth.vendor.com, WorkOS, Clerk…) failed: the central sent every OAuth request to the MCP server’s own host. It now uses the address the server announces. It still uses the MCP server’s host when the announced one is local (a local Activepieces announces localhost), the same host, or doesn’t resolve.

VS Code extension: agent-hangar-0.50.0.vsix attached.

v0.49.0 — long-context compaction, model per response and agent avatars

Choose a tag to compare

@valteresj2 valteresj2 released this 22 Oct 22:45

Added

  • Long context: chat agents compact the conversation instead of overflowing it. When a conversation goes over the agent’s context budget (60% of the model’s window by default, or execution.context_budget), large tool results leave the conversation and the agent reads them back with hangar_read_result. If it still doesn’t fit, the old history becomes a summary in the system prompt and the last messages stay whole. On by default; execution.compact: false turns it off. See docs/execution.md.
  • Model per response. With execution.light_model (auto, or a model id on the same connection), short and simple requests go to a cheaper model. Attachments, long requests or conversations, analysis, code and planning, Digital employee tasks and coding agents go to the agent’s model. That model also takes over when the light one fails, returns nothing, writes a broken tool call or keeps calling tools. Each call is billed at its own model’s price, and the usage event records the model that answered. auto picks the best-rated model that costs at most 40% of the agent’s model, and leaves free models out. Set both on the agent’s page (Execution) or through MCP. See docs/execution.md.
  • Agent avatars. Every agent has a character: 58 of them, from journalist and data scientist to firefighter and astronaut. Your AI picks one that fits the agent’s role when it builds the agent through MCP (avatar on register_agent, compose_agent and build_multi_agent; list_avatars lists them). If it doesn’t pick, the hangar chooses one from the name and goal. The owner swaps it on the agent’s page: click the avatar. It shows in the agent list, on the agent’s page, in My agents and in the org chart. Agents created before this get the one for their role. API: GET /api/avatars, PUT /api/agents/{slug}/avatar.

Upgrade: migration 0051 adds agents.avatar. Redeploy chat agents to get the new runtime (compaction and model per response).

VS Code extension: agent-hangar-0.49.0.vsix attached.

v0.48.2 — console page renders and your agents in the portal org chart

Choose a tag to compare

@valteresj2 valteresj2 released this 22 Oct 06:03

Fixed

  • Console: “Cannot set properties of null” on People and teams (and other pages) when you navigated while the previous page was still loading. The old page finished late and wiped the new one mid-render. Navigations now render one at a time: a new one waits up to 2 s for the previous to finish, and one that was already replaced is skipped.
  • Portal org chart showed none of the person’s regular agents. Only Digital employees appeared, so an agent you built (in the portal or through your AI) wasn’t there. Your personal agents, the ones you created and the ones of teams you maintain (the same list as My agents) now appear below you. These are links, and you can’t drag them.

VS Code extension: agent-hangar-0.48.2.vsix attached.

v0.48.1 — Docker MCP catalog icons and the active connector’s page

Choose a tag to compare

@valteresj2 valteresj2 released this 22 Oct 05:20

Docker MCP catalog: icons and the active connector’s page

Fixed

  • Icons the Docker MCP catalog points to but that no longer exist, Gmail’s among them, now fall back to the site’s favicon instead of a plain initial. Gmail gets its official icon. Replacement icons are cached under their own URL, so changing one never serves the old image.
  • An active connector’s page showed only the activation form, so it looked as if it hadn’t been saved. The page now says it’s on, links to the connector, and explains that filling the form only replaces the saved password or settings.

Tested

The full unit suite and lint, with a new test for the icon fallback. The fix was also checked on a running install: the Gmail, ramparts and llmtxt icons are served as images again.

The VS Code extension for this version is attached (agent-hangar-0.48.1.vsix).

v0.48.0 — Kernel sandbox on Kubernetes, Gmail OAuth plugin, Kubernetes e2e in CI

Choose a tag to compare

@valteresj2 valteresj2 released this 21 Oct 23:17

Kernel sandbox on Kubernetes, a Gmail plugin with each person's Google account, and the Kubernetes e2e in CI

Added

  • Kernel sandbox on Kubernetes. The Helm chart gets agents.runtimeClassName (K8S_RUNTIME_CLASS). Agents, harness jobs and plugins with code then run with a RuntimeClass that already exists in the cluster, such as gVisor (GKE Sandbox) or Kata, so untrusted code gets its own kernel. It's empty by default. See docs/kubernetes.md.
  • Gmail with each person's Google account. The example plugin examples/plugins/gmail.hangar-plugin.yaml searches and reads e-mail with OAuth2 and identity_mode: requester, without an app password. Its readme covers the Google Cloud setup. It's read-only; sending stays with the docker:gmail-mcp connector.
  • Kubernetes end-to-end test in CI. tests/e2e/k8s.sh installs the chart on k3s, then runs the smoke test and hangar test-drive against the cluster.

Tested

  • Unit tests: the full suite, with new ones for the runtime class on every pod kind and for the Gmail manifest.
  • The Kubernetes job: simulated from scratch, the chart installed on k3s, the smoke test (19 checks) and test-drive passed.
  • A real-LLM battery against an install on this code: 25/25 with openrouter-deepseek, covering agents, multi-agent, a Codex harness job, vision, Digital employees, shadow mode, DLP, budgets, the governed browser and memory.
  • Not tested: the runtime class with a real gVisor or Kata runtime (only the pod specs), and the Gmail plugin against Google (it needs your OAuth app).

The VS Code extension for this version is attached (agent-hangar-0.48.0.vsix).

v0.47.0 — Personal subscriptions removed; portal, Docker MCP gateway and My agents fixes

Choose a tag to compare

@valteresj2 valteresj2 released this 21 Oct 05:10

Personal subscriptions removed; fixes in the portal, the Docker MCP gateway and My agents

Removed

  • Harness jobs on a personal Claude or ChatGPT subscription (added in 0.46.0). Every harness agent runs on its LLM API connection again. The screens, the /api/me/subscriptions and /api/admin/subscriptions endpoints, harness.billing and harness.subscription_model are gone. Migration 0049 cleans up what 0.46.0 left behind.

Added

  • Portal → Meus agentes: a new section, Agents I created or maintain. It lists your regular agents (not Digital employees): your personal ones, those of the teams you maintain, and those you created, in the portal or by asking your AI over MCP. Each one shows its status, version, team, next scheduled run and cost over 30 days.
  • Matched by person, not by name. Each agent version now records who created it by user id (migration 0050). Two members with the same name don't see each other's agents, and a name change doesn't hide them. Versions saved earlier fall back to the person's name, e-mail or username, including the <e-mail> (app:Claude) that agents created through MCP were recorded with.

Fixed

  • Portal pages broke with "… is not defined". This hit Home, Decisions, the MCP OAuth consent screen (so connecting Claude could stall at "you started connecting but didn't finish") and an agent's page. They used functions from scripts that only the console loaded; the portal loads them now. The English-interface crawl now fails any page that ends on the error card.
  • Docker MCP catalog: a server turned on later only started after a gateway restart. The gateway's --watch lost track of its files after the first rename, so they are now rewritten in place.
  • Docker MCP catalog: Reconnect on a docker:<name> connector marked it as an error. It now asks the gateway whether that server is up.

Tested

The full end-to-end suite passed on a fresh install: smoke, Digital employees and plugins, day-to-day work, newer features, the English interface (with the error-card check), CopilotKit in a real browser, coverage, and CLI and operations, with backup and restore.

The VS Code extension for this version is attached (agent-hangar-0.47.0.vsix).

v0.46.0 — Harness jobs on a personal Claude or ChatGPT subscription

Choose a tag to compare

@valteresj2 valteresj2 released this 21 Oct 01:54

Harness jobs on a personal Claude or ChatGPT subscription

Coding jobs (Claude Code, Codex) use many tokens. Someone who already pays for Claude (Pro/Max) or ChatGPT (Plus/Pro) can now run the jobs they start on that subscription, instead of on the company's API connection. See docs/harnesses.md.

  • Only that person's jobs use it: jobs from the portal, from hangar jobs run and from their AI tool through the platform's MCP. Digital employees, schedules, tests and app keys always use the API, because they serve other people.
  • Off by default. An admin turns it on in Members → How they sign in, with a limit on concurrent jobs per subscription. Consumer subscriptions are individual licenses; check Anthropic's and OpenAI's terms first.
  • Connecting: each person connects their own under My sign-ins: the token from claude setup-token, or the auth.json from codex login. The credential is encrypted and never returned. API keys are refused, since they belong in an LLM connection.
  • Who pays: set per agent with harness.billing: api (default), subscription or subscription_then_api. On a subscription, no API key reaches the container.
  • Plan limits: the CLI's "usage limit reached" pauses the subscription until the reset time. The job then fails, or runs again on the API, and the job records why. A credential the vendor rejects is flagged, and Codex's refreshed sign-in is saved for the next job.
  • Metering: a job paid by a subscription costs US$ 0. It also records what it would have cost on the API, shown on the job, to the person and to the admin (savings over 30 days).

Tested

  • Unit tests, and a check of the real harness entrypoint with fake CLIs (harness/tests/subscription_check.sh, in CI): no API key leaks, the limit comes back with the reset time, and Codex's refreshed sign-in comes back.
  • The full end-to-end suite on a fresh install, including the subscription flow over the API.
  • Not tested: no job ran on a real Claude or ChatGPT subscription.

The VS Code extension for this version is attached (agent-hangar-0.46.0.vsix).