Reported issues for Labby

Pod holds 19 of 31 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 Labby.

Most discussed

Implement gateway enrichment hints for Code Mode upstreams

Summary

Implement gateway enrichment hints for Code Mode upstream namespaces.

This issue is self-contained. The root body gives the implementation summary, acceptance criteria, review decisions, and validation. Follow-up comments on this issue contain the full implementation plan and the full text of the epic plus all child beads.

Current Baseline Already Landed

Branch: codex/codemode-upstream-description

Commits already pushed:

• e96a6ed1 — docs: save codemode upstream descriptio

Read the thread · 2026-06-25 · closed · 9 comments

Code Mode catalog stability: remaining hardening after #260 (permanent tool registry, visible-contract hashing, monotonic publication, notification coalescing)

Context

#260 fixed the observed "Labby tools flapping": the gateway reconcile diff measured change against the raw pool.healthy_tools() set with no Code Mode filtering, so invisible upstream churn (an upstream becoming healthy, lazily discovering tools, the eager reload probe populating tool maps) flipped tools_changed and broadcast notifications/tools/list_changed. Clients rebuilt their connector namespace mid-turn and the in-flight call hit a stale LABBY.codemode binding — fail

Read the thread · 2026-07-24 · closed · 3 comments

Emit outputSchema + structuredContent for directly-listed tools; preserve structured content through Code Mode

Summary

Emit outputSchema + structuredContent for directly-listed tools, preserve structured content end-to-end through Code Mode, and surface output shapes in the catalog for hidden tools.

The Code Mode nuance (why this is not blanket)

• Under Code Mode, raw tools are hidden from list_tools — the client only sees execute/codemode. So per-tool outputSchema does not reach the client for hidden tools; it belongs in the catalog (codemode.describe) instead.
• Insid

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

Generalize MRTR input overlay for confirmations and primitive parameter completion

Summary

Generalize Labby's current destructive-confirmation MRTR flow into a policy-driven input overlay for upstream and synthetic tools.

The overlay should support:

1. destructive confirmation;
2. missing primitive parameter completion;
3. action-enum tools, including a two-round action-then-fields flow;
4. Code Mode-hidden MCP App callback calls without a separate hard-block path.

This is a gateway-originated overlay. It complements upstream-to-downstream request relay: the gateway ask

Read the thread · 2026-07-10 · open · 2 comments

Add rmcp-openapi support for OpenAPI-derived MCP upstreams

Summary

Research rmcp-openapi and implement a Lab integration path for turning OpenAPI specs into MCP servers/tools through the gateway/upstream runtime.

rmcp-openapi is a Rust crate for exposing OpenAPI definition endpoints as MCP tools using the official Rust MCP SDK. The current docs.rs surface exposes a Server that implements rmcp::ServerHandler, converts OpenAPI operations into tools via ToolGenerator, supports dynamic ToolFilter / ResponseTransformer, and carries runtime

Read the thread · 2026-06-03 · open · 2 comments

Node runtime split and role-specific rollout

Summary

Implement docs/superpowers/plans/2026-04-24-node-runtime-split.md. Split lab serve into explicit controller and node runtime paths, stop deployed nodes from initializing controller-only surfaces, build role-specific controller/node artifacts, make nodes update verify real readiness and WebSocket reconnects, then prove the path with full verification and live rollout.

Beads

Epic: lab-686q

Plan

• docs/superpowers/plans/2026-04-24-node-runtime-split.md
• `docs/NODE_R

Read the thread · 2026-04-25 · closed · 2 comments

Param-completion elicitation for action-enum tools (post-action-resolution primitive projection)

Summary

Param-completion elicitation for action-enum tools — the missing-primitive-param overlay from #208's Fields rule, adapted to Labby's nested-action-with-enum tool pattern.

The interaction (why this earns its own issue)

• MCP elicitation schemas are restricted to a flat object of primitives — no oneOf/if-then, no nested objects/arrays.
• Most Labby / rmcp-template servers shape tools as { action: enum, <action-specific params> }, so a single form cannot express the

Read the thread · 2026-07-10 · closed · 1 comment

Spike: evaluate rmcp tower layers for the dispatch gate chain + elicitation overlay

Summary (spike)

Evaluate rmcp's tower feature for restructuring the dispatch gate chain and hosting the #208 elicitation overlay as composable layers.

Context

• Gates in crates/labby/src/mcp/call_tool.rs are hand-rolled early returns (codemode → visibility → action → hidden → scope → elicitation → builtin → upstream). #208 bolts the overlay onto this chain.
• rmcp exposes a tower feature (dep:tower-service), but it is unclear whether that is protocol-level request middlewa

Read the thread · 2026-07-10 · closed · 1 comment

Most recent

Retain and page oversized Code Mode results by handle

Summary

Add an optional retained-result path for Code Mode outputs that are expensive, rate-limited, non-idempotent, or inherently too large to regenerate safely after the response envelope truncates them.

This is Phase 2 of #217. The primary behavior remains reducing inside the sandbox before returning. Retained paging is a selective fallback, not the default result path.

Motivation

Re-running a tool with better projection code is acceptable for cheap idempotent reads. It is a poor fa

Read the thread · 2026-07-27 · open · 0 comments

Permanent synthetic-tool registry and full client-visible descriptor hashing

Context

#261 fixed the production symptom and most of the catalog-stability plan through #263, #264, and #267:

• detached reload cancellation is deterministic;
• catalog changes are evaluated per peer and route scope;
• notifications are coalesced and withheld during open tool turns;
• publication ordering was verified to be serialized by the existing mutation lock.

Two structural items from #261 remain. The release PR closed the umbrella issue, but #264 explicitly notes that full descript

Read the thread · 2026-07-27 · closed · 0 comments

Streamable HTTP over Unix sockets with optional SO_PEERCRED authentication

Summary

Support connecting to co-located MCP upstreams over Unix domain sockets using rmcp 3's transport-streamable-http-client-unix-socket transport, with optional filesystem and SO_PEERCRED authentication for trusted local services.

Current state

Labby 1.7.0 uses rmcp 3.0.0-beta.2 and enables only transport-streamable-http-client-reqwest. Upstream configuration and connection code currently expect HTTP(S) URLs. No Unix-socket client, listener, socket-path configuration, or pee

Read the thread · 2026-07-11 · closed · 0 comments

Decide rmcp Tower and request-state adoption

Summary

Decide whether Labby should adopt two rmcp 3 features that are available but not enabled: protocol-level Tower service composition and request-state integrity protection.

This issue consolidates the former #215 Tower spike. The basic research question is now answered; the remaining work is an adoption decision backed by a small prototype.

1. Tower protocol service

Finding

rmcp 3.0.0-beta.2 exposes service::tower::TowerHandler<S, R>. It implements rmcp's protocol `Ser

Read the thread · 2026-07-10 · open · 0 comments

Set ToolAnnotations on builtin/gateway tools + propagate upstream annotations downstream

Summary

Set ToolAnnotations on Labby's own tools and propagate upstream annotations through the aggregated list_tools.

Current state

• Annotations are consumed to derive destructive (crates/labby-gateway/src/upstream/pool/helpers.rs:368 — reads destructive_hint, falls back to !read_only_hint, fails closed).
• But Labby's own builtin/meta tools likely do not set hints, and upstream annotations may not be propagated to the downstream client.

Plan

• Annotate bu

Read the thread · 2026-07-10 · closed · 0 comments

URL-mode elicitation (elicit_url / UrlElicitationParams)

Summary

Add URL-mode elicitation (elicit_url / ElicitRequestParams::UrlElicitationParams) alongside the existing Form path.

Motivation

• Only Form elicitation is used today (crates/labby/src/mcp/elicitation.rs). URL mode suits auth-style "open this URL" flows and MCP App clients that prefer a hosted form. Directly addresses #208 open question 3.

Plan

• Add an elicit_url(context, message, url, elicitation_id) helper.
• Gate on ElicitationCapability.url via `supported_elici

Read the thread · 2026-07-10 · closed · 1 comment

Resource subscriptions passthrough (enable_resources_subscribe + resources/updated aggregation)

Summary

Add resource subscription passthrough: advertise resources/subscribe, route subscribe/unsubscribe to the owning upstream, and fan resources/updated notifications back to subscribed downstream clients.

Current state

• crates/labby/src/mcp/server.rs:169 enables resources + resources_list_changed but not enable_resources_subscribe().
• The stdio bridge already forwards subscribe/unsubscribe (bridge.rs:20), so plumbing is partial.

Plan

• Add `.enable_resou

Read the thread · 2026-07-10 · closed · 1 comment

Destructive-action gate should honor lab:admin scope — coordinate with elicitation overlay (#208)

Summary

Two coupled gate problems around destructive upstream tools. Filing this as the coordination point between the elicitation-overlay work (#208) and the standing admin-scope bug.

• #208 makes the widget-callback bypass path attempt elicitation instead of hard-returning confirmation_required.
• docs/destructive-gate-admin-scope-bug.md documents that the Code Mode destructive gate ignores lab:admin entirely — it keys off surface.allow_destructive_actions(), driven pure

Read the thread · 2026-07-10 · open · 0 comments

Code Mode bypasses the confirmation_required gate for destructive upstream tools

Summary

Tools classified as destructive are refused on the widget-callback path but execute without challenge through Code Mode. The confirmation gate is enforced per-transport rather than per-tool, so codemode is an unauthenticated bypass around it.

This is not theoretical — it was used (unintentionally) to create a real GitHub issue during a debugging session on 2026-07-10.

Reproduction

1. Direct call is refused

// labby::issue_write
{"method":"create","owner":"jmagar

[Read the thread](https://github.com/dinglebear-ai/labby/issues/207) · 2026-07-10 · closed · 0 comments

### [codemode] Thread upstream outputSchema into ToolDescriptor so Output types aren't `unknown`

Parent: #185 · Separate track

## Reality — smaller than it looks
The pipeline already supports output types end to end:
- `ToolDescriptor.output_schema: Option<Value>` **exists** (types.rs L106); the `ToolDescriptor::tool(…, output_schema)` ctor takes it (L135–140).
- `ts_signatures::generate_tool_types(…, output_schema)` emits a real `Output` type and only falls back to `"unknown"` when the schema is `None` (ts_signatures L74–76).

So every tool's `Output` is `unknown` for exactly one reason: 

[Read the thread](https://github.com/dinglebear-ai/labby/issues/193) · 2026-07-04 · closed · 1 comment

### [codemode] Thread CallContext (execution_id + ordinal) to host.call_tool for _meta enrichment

Parent: #185 · Depends on: #190, #191

## Goal
Enrich the same `_meta` with `execution_id` + a monotonic `call_ordinal` so every sandbox-originated upstream call auto-correlates to its Code Mode run and to the `calls[]` telemetry — no sandbox-authored trace, no author discipline.

## Decision (locked)
Thread a **neutral `CallContext` param** into `CodeModeHost::call_tool` rather than smuggling meta through `params` — preserves the trait's deliberately neutral vocabulary (host.rs L5–6, L78–85).

[Read the thread](https://github.com/dinglebear-ai/labby/issues/192) · 2026-07-04 · open · 0 comments

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