Reported issues for Dibs

Pod holds 17 of 18 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 Dibs.

Most discussed

Shipped plugins point at ~/.agents and a binary named agents, so they install broken

Found by a gpt-5.6-sol audit of the org, then verified by grep against main. Filing rather than patching — these are integration files with behaviour I cannot test.

These are not rename leftovers in prose. They are paths and commands a user follows, and following them fails.

Verified against main

Read the thread · 2026-08-19 · closed · outside contributor · 1 comment

Identity is coupled to the stdio bridge, and 2026 is the revision that lets it stop being

"Which transport is future-proof, stdio or Streamable HTTP?" is the wrong axis, and answering it either way locks in a constraint 2026 just removed. The forward-looking answer is that Dibs should stop caring, and today it cannot.

What 2026 actually changed

Before 2026, a session was connection-scoped: initialize established it, and it lived and died with the connection. That coupled identity to transport by construction — whoever held the connection held the session.

2026 removed the

Read the thread · 2026-08-17 · closed · outside contributor · 2 comments

Claude Code 2.1.233 has the 2026 machinery and still opens on 2025-11-25

Corrected 2026-08-17, same day it was filed. This issue originally said Claude Code had no MCP 2026 support. That was true of the installed build and false of the released one, which is the exact error this repository keeps making: a measurement taken once and treated as a property.

What is actually true

And it is not merely present. M

Read the thread · 2026-08-17 · open · outside contributor · 2 comments

Claude Desktop ships the 2026-07-28 wire codec — measure whether it negotiates it with Dibs

Claude Desktop 1.30096.5 carries real MCP 2026-07-28 machinery. Whether it uses it against Dibs is unmeasured, and that gap is the point of this issue.

What is in the binary

From Contents/Resources/ion-dist/assets/v1/c2a6d07ee-*.js:

function qs(e){ return e >= "2026-07-28" }                 // version predicate
wa = { era: "2026-07-28", hasRequestMethod: ..., ... }      // an era wire codec
case "server/discover": return Ca("2026-07-28")             // the 2026 entry point

Read the thread · 2026-08-17 · open · outside contributor · 1 comment

opencode: wake path works — track its move to MCP 2026-07-28

Tracking issue. Nothing is broken here; this exists so the next protocol move is noticed rather than discovered.

Read against opencode at 2cba7e2 (dev, 2026-08-17).

Where it stands

The wake path works, and it is the one that was driven live. An in-process plugin on the chat.message hook injects mail as a synthetic message part; a real model read the mail and replied unprompted. See plugins/opencode/ and WAKE-MECHANISMS.md. No subprocess, nothing that makes Dibs a harness driv

Read the thread · 2026-08-17 · open · outside contributor · 1 comment

Codex wake path: mcp_tool hooks are one wire from working — re-check the executor, not the enum

Dibs shipped plugins/codex/hooks.json for three releases and not one entry in it ever fired. It has been removed (see the commit that added TestShippedHooksUseOnlySupportedTypes). This issue tracks when it can come back.

Why it never fired

The file used type: "mcp_tool", on the strength of a Rust enum found in a Codex source tree. The enum was real. It was not a feature.

State on 2026-08-17, codex main 32a383c0:

Read the thread · 2026-08-17 · open · outside contributor · 3 comments

Codex speaks MCP 2026-07-28 today: adopt it, and prove it in CI

WAKE-MECHANISMS.md says nobody speaks MCP 2026. That is now out of date, and the harness that changed it is Codex.

Measured, 2026-08-17

Codex Desktop 0.148.0-alpha.9 (the binary inside ChatGPT.app), against codex main 32a383c0:

codex exec -c 'mcp_servers.dibs.env={CODEX_MCP_PROTOCOL_VERSION="2026-07-28"}' ...

With that set, Codex sends server/discover rather than initialize — the 2026-07-28 stateless entry point. Confirmed twice: once against a probe MCP server that

Read the thread · 2026-08-17 · closed · outside contributor · 3 comments

Design: coordination across more than one machine

Lanes coordinates one machine. The obvious next question is a fleet spread over several, and this issue is the place to argue about how, before any of it is built.

What already works. The transport is not the hard part. lanesd serves MCP over HTTP and the board over the same listener; binding a non-loopback address and putting TLS in front of it is a small change. Almost nothing else survives the move.

What breaks, and why each is a design question rather than a task:

• *Liveness.

Read the thread · 2026-08-11 · open · outside contributor · 2 comments

Most recent

Notifications are macOS-only: Linux operators cannot be asked to approve anything

notify.Available() is runtime.GOOS == "darwin" (internal/notify/notify.go:272), and the whole human-approval path runs through notify.Ask (internal/engine/human.go:464, human.go:509).

On Linux the operator is therefore never asked. Requests that need a person, role grants, mailbox adoption, and anything else routed to the human, fall back to waiting on the board until somebody happens to lo

Read the thread · 2026-08-22 · open · outside contributor · 0 comments

Every generated config prescribes a stdio bridge, so N agents cost N processes the daemon does not need

Raised by the user: stdio bridges scale linearly per agent, so n concurrent agents on one machine means n bridge processes. Measured, and it is real, but the interesting part is that it is avoidable today.

Measured, on one developer machine

bridges=9  total_rss=72MB  mean=8.0MB  fds=13 per bridge

Nine agents idling cost 72 MB of pure adapter. Extrapolating: 50 concurrent agents ≈ 400 MB, 100 ≈ 800 MB, before any of them does work. Each also holds ~13 fds and a long-lived co

Read the thread · 2026-08-22 · open · outside contributor · 0 comments

Registry entry has no install path, so agents find Dibs and then guess

Found while auditing Agenxy's public discovery surfaces. Filing rather than fixing — the resolution is a distribution decision that belongs to this repo.

What is wrong

io.github.Agenxy/dibs is live and active in the official MCP registry at 0.0.5, published 15 August. It carries name, title, description and repository. It has no packages block and no remotes.

So an agent can discover Dibs and then has nothing machine-readable telling it what to fetch or how to launch the server

Read the thread · 2026-08-19 · open · outside contributor · 0 comments

adopt says "an abandoned agent OF YOURS" and lets you name anyone's mailbox

Release blocker. The adopt parameter's schema states a constraint the code never enforces.

adopt: "on a request: ask to reclaim an ABANDONED agent OF YOURS, by id"

"of yours" is checked nowhere. Any agent may put any id there. The only ownership rule in the codebase guards the operator's row specifically:

// engine/human.go, mayApproveGrant
if m.Adopt != "" && human != "" && m.Adopt == human && actor.ID != human {
    return core.ErrHumanMailboxIsTheirs
}

That was add

Read the thread · 2026-08-17 · open · outside contributor · 0 comments

Release blocker: mail to this project's maintainer sat unread, and every recovery path was also asleep

Release blocker for v0.0.6. Found by dogfooding failing in the most embarrassing possible way: a message addressed to this project's maintainer sat unread for an hour while a maintainer session worked on this repository all day.

What happened

web-lead-2 sent mail to dibs-maintainer (serial 643, 11:17). It was never read. The operator noticed, not Dibs.

The wake path is not the fault. The daemon reports hooks_live: true for this session, and the lifecycle hooks reached it befo

Read the thread · 2026-08-17 · open · outside contributor · 0 comments

ChatGPT desktop / Codex: 2026-07-28 negotiated, but not the full surface

Split out of #22, which covers the fact that Codex negotiates 2026-07-28 and Dibs already answers it. This one is about how much of the revision it actually implements, because "negotiates 2026" and "supports 2026" are not the same claim.

What Codex has

Verified against the ChatGPT.app binary 0.148.0-alpha.9 and codex main 32a383c0 (2026-08-17):

Read the thread · 2026-08-17 · open · outside contributor · 1 comment

subscriptions/listen may be the wake path we have been looking for: no hook, no subprocess

Every wake path Dibs has is per-harness glue. Claude Code gets one because it has mcp_tool hooks; opencode gets one because it has in-process plugins; Codex gets none, and the only mechanism it offers is the subprocess WAKE-MECHANISMS.md §6 rejected. Each is a different shape, each drifts, and #23 is the bill for that.

MCP 2026-07-28 may make all of that unnecessary.

The observation

Claude Code 2.1.233 negotiates 2026-07-28 with Dibs today (#29), and its binary carries `subscriptions

Read the thread · 2026-08-17 · open · outside contributor · 1 comment

hermes-agent: a 2026-07-28-aware MCP client that still negotiates legacy

Tracking issue. Read against hermes-agent at 4323c67dc (2026-08-17).

Where it stands

Hermes is the only harness in this set whose MCP client already reasons about 2026-07-28 while not yet negotiating it. tools/mcp_tool.py handles the transition explicitly:

• it pins a protocol version older than the newest its SDK knows, deliberately
• it detects a server that answers a legacy initialize with a rejection and identifies that as "a 2026-07-28-only server"
• it notes which field

Read the thread · 2026-08-17 · open · outside contributor · 1 comment

gemini-cli: no Dibs plugin at all, and its runtime hooks may be a wake path

Dibs ships plugins for claude-code, claude-desktop, codex and opencode. gemini-cli has nothing, and it has never been assessed. Read against gemini-cli at 9a15c45 (2026-08-16).

What it has

Lifecycle hooks, with two handler types (packages/core/src/hooks/types.ts):

export enum HookType {
  Command = 'command',
  Runtime = 'runtime',
}

Runtime is the interesting one. Codex offers only subprocesses, which is why Dibs will not wake an agent there; a runtime hook is in-pr

Read the thread · 2026-08-17 · open · outside contributor · 1 comment

The remaining reports are on the project's issue tracker.