Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/lobu/issues.md or /mcp/lobu/issues.json, or Pod over MCP.

Reported issues for Lobu

Pod holds 22 of 63 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Lobu.

Most discussed

Replace manual Dockerfile generation with native devcontainer CLI for 10-second worker startup

Summary

Implement native @devcontainers/cli integration to replace manual Dockerfile generation, enabling full devcontainer feature support and reducing worker startup time from 2-3 minutes to under 10 seconds.

Current Problem

Our current implementation:

Read the thread · 2025-08-30 · closed · 7 comments

[MCP reliability] Knowledge consistency, connector diagnostics, run history, metrics bounds, and latency

Summary

A production MCP E2E run exposed several medium-priority reliability and observability gaps. None individually blocks core CRUD, but together they make agents misinterpret empty results, retry incorrectly, and struggle to diagnose slow or inconsistent behavior.

This issue groups the remaining related operational concerns rather than splitting them into separate tickets.

1. Knowledge consistency and supersession semantics

Observed

Read the thread · 2026-07-20 · closed · 4 comments

Definition of tenant and their exclusive zone

It would be good to get clarity on this, at the top of it, what is a tenant? and what are its exclusive capabilities? (Capabilities that are only accessible to this owning tenant)

  1. Is a Telegram user a Tenant? How about a Telegram group? And a Telegram group that has many topics?
  2. As a Telegram user in a DM with the bot, am I able to setup a remote MCP with credentials to my personal gmail/calendar account?
  3. In a Telegram a group, can I further setup 1 or more shared accounts? Can thi

Read the thread · 2026-07-28 · closed · external user · 3 comments

Evaluate OpenClaw memory-wiki compatibility over Lobu watchers/actions/feedback

Context

OpenClaw has a first-party memory-wiki extension that exposes native wiki concepts/tools (wiki_search, wiki_get, wiki_apply, wiki_status, wiki_lint) and a compiled vault model (sources/, entities/, concepts/, syntheses/, reports/, .openclaw-wiki/cache/agent-digest.json, claims.jsonl). We want Lobu to support that experience without making Lobu MCP more complex or turning the core codebase into a second wiki engine.

Reference: https://github.com/openclaw/ope

Read the thread · 2026-05-10 · closed · 3 comments

Guardrail: DNS pinning in worker HTTP proxy to prevent rebinding (TOCTOU)

Problem

packages/gateway/src/proxy/http-proxy.ts:229 resolves the target hostname fresh per request with dns.lookup(hostname, {all: true, verbatim: true}) and no caching or pinning. The proxy validates the resolved IP isn't in a blocked range, then connects — but the IP used for the connection can diverge from the validated one if the resolver flips (classic DNS rebinding / TOCTOU).

An attacker who controls a DNS record for an allowlisted domain can answer with a public IP during validat

Read the thread · 2026-04-21 · closed · 3 comments

Demo gate: prove ChatGPT → governed Mac computer use through the native daemon

Goal

Prove the exact Reddit-demo path from the real ChatGPT host to a real Mac through Lobu, using only the shipped MCP, approval, device-poll, and native-bridge paths.

This is a verification gate, not a new computer-control implementation.

Existing path to exercise

  1. A fresh Lobu for Mac install signs in and explicitly enables Mac Computer Use and Mac Shell.
  2. ChatGPT connects to the unscoped Lobu MCP endpoint through OAuth.
  3. ChatGPT discovers the device-backed `apple.computer_use

Read the thread · 2026-08-23 · open · 2 comments

[MCP readiness] Production blockers and SDK contract inconsistencies found in end-to-end test

Summary

An end-to-end MCP readiness test was run against the production MCP endpoint on 2026-07-20 using an owner/admin account and a private test workspace. The core data model is functional, but the MCP is not ready for an unrestricted public/self-serve launch because discovery, runtime execution, transport reliability, scheduler health, classifier persistence, and deletion contracts disagree in several places.

This issue is intentionally an umbrella checklist so each item can be

Read the thread · 2026-07-20 · closed · 2 comments

feat(gateway): generic inbound webhook connections — push-source primitive (use case #1: Sentry→Slack triage)

Problem

Lobu talks out to chat platforms and pulls in via connectors (pull-only — ConnectorRuntime.sync()), but no external system can push events into Lobu. Every SaaS tool emits webhooks (Sentry, GitHub, Stripe, healthchecks, CI); none of them can reach an agent today.

Use case #1 (dogfood, also the acceptance test): Sentry's free plan blocks the native Slack integration, but its legacy per-project WebHooks plugin POSTs new-issue payloads to any URL on every plan. Goal: *Sen

Read the thread · 2026-06-12 · closed · 2 comments

Most recent

Gateway withholds compiled_code from a device that does not execute the connector natively, stranding every claimed run

Note: this issue was rewritten after the original report, which blamed the worker image and claim admission. The root cause is gateway-side, in the poll response's connector-code delivery. See the correction comment below.

Describe the bug

When the gateway hands a claimed run to a device worker, it decides whether to ship the connector bundle with deviceWillExecuteNativeConnector (packages/server/src/worker-api/poll.ts):

const deviceWillExecuteNativeConnector =
  isUserSco

[Read the thread](https://github.com/lobu-ai/lobu/issues/3214) · 2026-08-28 · closed · 1 comment

### Operation run history reports the connection's current device pin, retroactively rewriting which device ran a completed run

**Describe the bug**

`device_worker_id` on an operation run (as returned by `operations.listRuns`) does not record the device that executed the run. It reflects the connection's **current** `device_worker_id` at read time, so re-pinning a connection retroactively changes what already-completed historical runs report.

This makes run history unusable for answering "which device ran this?", and it silently misattributes past executions after any re-pin.

**To Reproduce**

1. Execute an operation 

[Read the thread](https://github.com/lobu-ai/lobu/issues/3213) · 2026-08-28 · open · 1 comment

### connections.update accepts and echoes a device pin to an offline device, then reconcile silently reverts it seconds later

> **Note:** this issue was substantially rewritten after the original report. The first version claimed reconcile was overriding a deliberate pin to a *fresh* device, contradicting the documented contract. That premise was wrong — the target device was already offline. See the correction comment below. The narrower issue described here still stands.

**Describe the bug**

`connections.update({ device_worker_id })` accepts a pin to a device that is **offline / outside the fresh set**, returns suc

[Read the thread](https://github.com/lobu-ai/lobu/issues/3212) · 2026-08-28 · open · 1 comment

### feat(evidence): record governed read receipts for dataset lineage

## Summary

Record compact, trusted, run-linked receipts for live source and governed evidence reads, while continuing to model analytical datasets using existing events and attachments.

**Priority:** P0
**Complexity:** Medium (3/5)
**Estimate:** 180–300 production LOC; 250–400 test LOC; 100–180 project/docs LOC
**Migration:** none

## Existing primitives to reuse

`ArtifactStore`, `upload_file`, event attachments, `knowledge.save/read`, stable `lobu://event` resources, indexed `events.run_id/e

[Read the thread](https://github.com/lobu-ai/lobu/issues/3203) · 2026-08-27 · open · 0 comments

### Local Agent Sessions in Recent: device-backed connector for Codex/Claude/OpenCode/Pi sessions

### Goal

Surface all local AI agent sessions (Codex, Claude Code, OpenCode, Pi) running or previously run on a user's Mac inside the web app's **Recent** section, plus a glanceable **Mac overlay** ("3 running · 7 active in last 5m"). Users must not see an empty Recent on install — historical backfill comes free from local metadata stores, no hooks required.

Outcome of the design session on 2026-08-24 (codex session `01a035a0`). No code written yet; worktree is prepped and clean.

### Agreed de

[Read the thread](https://github.com/lobu-ai/lobu/issues/3170) · 2026-08-24 · open · 1 comment

### bug(sdk): automations.trigger hides manual-open execution ownership

## Problem

The public SDK metadata currently describes automations.trigger as:

“Trigger an immediate Automation run and dispatch it to its assigned agent.”

That is false for a valid manual-only Automation with neither agent_id nor device_worker_id. In that case the server intentionally creates a manual-open pending run and performs no dispatch. The external MCP client that called trigger must own the rest of the flow:

1. client.automations.trigger({ automation_id })
2. client.knowledge.read(

[Read the thread](https://github.com/lobu-ai/lobu/issues/3083) · 2026-08-22 · closed · 0 comments

### feat(auth): scope which worker tokens may open direct MCP sessions (source discriminator)

Raised by the #2974 review, deferred there because the exposure is PRE-EXISTING, not introduced by that PR: the old direct-auth lane keyed on the `x-lobu-memory-direct-auth: 1` header, which is request-controlled — any holder of a valid worker token (including a chat sandbox's own deployment-lifetime WORKER_TOKEN) could always attach the header themselves and open an admin-scoped `/mcp/<orgSlug>` session that skips the gateway proxy's pre-tool guardrails. #2974 removed the header requirement for

[Read the thread](https://github.com/lobu-ai/lobu/issues/2979) · 2026-08-20 · closed · 0 comments

### get_approval cannot render or resolve approvals created through client.org()

## Problem

The unscoped OAuth SDK supports cross-workspace calls through `client.org('<target>')`, including connector operations. An approval-gated operation can therefore be correctly created in a target workspace while the MCP session itself remains bound to another workspace.

The top-level MCP Apps approval surface cannot follow that operation into its owning workspace.

Example shape:

`run_sdk` session bound to workspace A:

`client.org('workspace-b').operations.execute(...)`

=> correct

[Read the thread](https://github.com/lobu-ai/lobu/issues/2878) · 2026-08-18 · open · 0 comments

### MCP App: toolOutput without structuredContent overwrites widget snapshot on ChatGPT re-render

## Bug

When a ChatGPT MCP App re-renders (page reload, conversation reopen), the dashboard charts fall back to raw JSON (`{ "id": 5193493 }` with "1 field") instead of the rendered `lobu/view`.

## Root Cause

In `readOpenAiCompatSnapshot` (`packages/owletto/src/mcp-apps/_shared/openai-compat.ts`), when `toolOutput` exists but lacks `structuredContent`, `dataFromToolOutput` returns the raw `toolOutput` object (line 75). This takes precedence over the persisted widget snapshot (line 176-178), ev

[Read the thread](https://github.com/lobu-ai/lobu/issues/2876) · 2026-08-18 · closed · 1 comment

### Durably audit every entity write denial after rollback, without storing proposed values

> **Status: READY. Product/storage decisions are fixed below; do not reopen them in implementation.**

## Goal

Every caller-visible entity write refusal caused by Lobu's **permission policy** or **entity write rules** leaves a durable, queryable audit record even though the mutation itself did not commit.

Today a successful update can emit a change event while a denied write often leaves only a log line. An `escalate` gets a durable approval run; a `deny` should not disappear from the durable 

[Read the thread](https://github.com/lobu-ai/lobu/issues/2866) · 2026-08-18 · closed · 1 comment

### Connector-declared edges (1/2): manifest references + server preflight, no edge writes

> **Status: READY. This issue is manifest/schema + validation only. It must not write `entity_relationships`.**

## Goal

A connector can already declare **event → entity** attribution rules. Add the minimum declarative surface that lets one event kind say “the entity resolved by attribution A relates to the entity resolved by attribution B using relationship type T.”

Do not create a second identity resolver or repeat endpoint identity specs inside the relationship declaration. The existing att

[Read the thread](https://github.com/lobu-ai/lobu/issues/2856) · 2026-08-18 · closed · 0 comments

### Edge change history covers 3 of 13 write sites — decide the chokepoint

Edge change history shipped in #2807 covers the three MCP handlers (`handleLink`, `handleUnlink`, `handleUpdateLink`). It covers 3 of 13 edge write sites.

Still recording nothing:

| file | sites |
|---|---|
| `packages/server/src/utils/entity-merge.ts` | 3 (repointing on merge/unmerge) |
| `packages/server/src/authz/channel-about.ts` | 3 |
| `packages/server/src/authz/access-graph.ts` | 2 |
| `packages/server/src/utils/auto-linker.ts` | 1 |
| `packages/server/src/gateway/routes/public/github-t

[Read the thread](https://github.com/lobu-ai/lobu/issues/2809) · 2026-08-16 · open · 0 comments

### feat(cli): first-class drift/diff view (lobu diff) incl. reaction-script fingerprint

## Problem

`lobu apply --dry-run` computes a full config-vs-deployed diff but only surfaces details for **update** rows and **blocking** drift. There is no way to see "what has drifted" (all config-vs-deployed differences) without running an apply, and **reaction scripts are write-only** — the Behavior list API does not return them, so a stale reaction is invisible in the plan.

## What exists today

- `computeDiff` already does a three-way (desired / remote / baseline) diff across agents, Beha

[Read the thread](https://github.com/lobu-ai/lobu/issues/2787) · 2026-08-15 · open · 0 comments

### Spawned binaries can bypass the egress allowlist (allowNet: true)

## What

Spawned binaries registered by the embedded worker run with `allowNet: true` (`just-bash-bootstrap.ts`), which becomes `--share-net` under bwrap and `(allow network*)` under sandbox-exec. They therefore have unrestricted host networking.

The code's stated control is the proxy:

> Spawned binaries reach the network through HTTP_PROXY → gateway, which already enforces the per-agent domain allowlist.

That holds only for a binary that *chooses* to honor `HTTP_PROXY`. It is a convention, n

[Read the thread](https://github.com/lobu-ai/lobu/issues/2244) · 2026-07-28 · open · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/lobu-ai/lobu/issues).