pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

Reported issues for floom

Pod holds 24 of 144 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 floom.

Most discussed

Custom MCP tools cannot run workers created through hosted MCP: filesystem worker directory not found

Summary

A custom MCP tool registered against a worker created through the production MCP workers.create path fails because the custom-tool dispatcher looks for a filesystem worker directory instead of using the persisted DB/files backing the worker.

Reproduction

Against production workeros-prod MCP endpoint:

  1. Create a temporary worker through workers.create.
    • Worker id: mcp-result-worker-1782170840
    • Creation succeeded.
  2. Register a custom MCP tool backed by that worker

Read the thread · 2026-06-22 · open · 8 comments

[agent-interface][P1] MCP connection 'test' does not actually call the MCP server

From the 2026-06-08 audit. Owner: Vivek.

Observed

POST /connections/mcp -> 200 active. POST /connections/{id}/test -> 200 'saved; checked when a worker runs' — i.e. persistence only, no initialize/tools-list. Agents can't validate a connection before wiring it.

Fix

Extend test to initialize + tools/list for HTTP/SSE MCP; return tool count, transport/auth errors, allowed-tool mismatches. Effort: M.

Report: docs/audits/agent-interface-readiness-2026-06-08.md

Read the thread · 2026-06-08 · closed · 5 comments

[P1][cloud][cli] Cloud session expires mid-task: workspaces create succeeds, then workers push fails "token is not valid for this workspace" / "session expired" minutes later

What happened

Provisioning a new secretary workspace + worker in one sitting on AX41 with @floomhq/workeros@4.2.1 (cloud, workeros-api.floom.dev):

  1. workeros workspaces create "fede-secretary" → ✓ Created workspace fede-secretary (ws_8a3131705c4649). Active workspace updated. (authenticated call succeeded)
  2. Built + workers validate a worker locally → ✓ passes
  3. workeros workers push fede-secretary-inbox → ✗ `Request was forbidden. API said: token is not valid for this worksp

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

[Feature] Emily should persist conversation memory to the brain

Problem

Emily (the workspace agent) has no long-term memory across conversations. Every chat starts from zero — she cannot remember preferences, past decisions, or recurring topics from earlier sessions.

The conversation history table stores raw transcripts, but:

  1. It is not readable by Emily in future sessions (history is limited to the last 50 messages of the current thread).
  2. It is not summarised — raw chat is too verbose to inject into the system prompt.
  3. It is not structured for

Read the thread · 2026-06-10 · closed · 4 comments

P1: Migrate legacy Composio connections to scoped allowlists

Description

Legacy manifest connections: [gmail] grants full app tool access. Structured allowed_tools is enforced; legacy strings are not.

Parent: #610

Evidence

  • docs/audits/security-product-audit-2026-06-01.md P1: legacy connections unrestricted
  • declared_composio_connections() treats legacy strings as unrestricted
  • Stock workers may still use legacy format

Expected

  • Audit all stock workers for legacy connection declarations
  • Migrate to structured connec

Read the thread · 2026-06-08 · closed · 4 comments

P1: Agent runtime hardening — concurrency, cancel fail-open, runs.runner metadata

Description

Three agent-lane reliability gaps block 10/10 runtime maturity. Parent: #610.

1. Concurrency — "Event loop is closed"

Evidence: Prod smoke weekly_update needed retry (docs/workers/SMOKE-RESULTS-2026-05-29.md). G3 audit: solo 10/10, fails under 2+ concurrent runs (docs/audits/full-audit-2026-05-29-0841.md).

Fix exists partially: LoopLocalModelProvider (agent_driver.py:331–346, test_agent_driver_concurrency.py) — prod still saw recurrence.

Acceptance:

Read the thread · 2026-06-08 · closed · 4 comments

Stdio MCP runs.watch times out after successful prod run

Live prod repro

Environment: local @floomhq/floom built from repo engine/apps/mcp, connected to https://workeros-api.floom.dev with:

  • WORKEROS_CLOUD=1
  • WORKEROS_API_BASE=https://workeros-api.floom.dev
  • WORKEROS_API_TOKEN=<fresh PAT>
  • WORKEROS_WORKSPACE_ID=ws_7ff0773b15684f

Stdio MCP read paths passed:

  • initialize
  • tools/list -> 58 tools
  • workers.list
  • workers.get
  • runs.list
  • runs.get
  • secrets.list
  • connections.list
  • contexts.list

Then started

Read the thread · 2026-06-23 · closed · 3 comments

MCP workers.run should expose run_id in structuredContent for tool chaining

Summary

Live prod /mcp-tools/serve workers.run returns the new run_id only inside text content, with no structuredContent. This makes chaining to runs.watch brittle for MCP clients.

Live prod evidence

Environment: https://workeros-api.floom.dev, workspace vbellala, 2026-06-22.

Temporary worker: codex-prod-mcp-20260622233627-worker.

workers.run returned text content:

{
  "status": "running",
  "run_id": "run_e9d207a61ad8"
}

But the MCP result did not exp

Read the thread · 2026-06-22 · closed · 3 comments

Most recent

connections_test mutates persistent connection state as a side effect, and connections_list shows "active" for connections that actually fail live (401/404)

Summary

Two related trust/correctness issues with connection health-checking:

  1. connections_test has a persistent side effect — calling it flips the stored connection status from active to failed and updates last_checked_at, even though a "test" / health-check call should be read-only (or at minimum, that side effect should be documented and intentional, not incidental).
  2. connections_list reports "active" for connections that fail live — all 3 configured MCP connections

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

triggers_list unusable at scale (4MB/351 triggers, no filter/pagination) and integrations_catalog exposes pagination metadata but accepts no params

Summary

Two related pagination/filtering gaps on list-style MCP tools:

  1. triggers_list returns ~4MB of data (351 triggers spanning 41 unrelated toolkits) completely unfiltered — this blows past reasonable MCP response/token limits. Even filtered down to a single relevant app, the response is still ~430KB. There is no limit, page, or fields parameter to control response size.
  2. integrations_catalog reports its own pagination metadata (1048 items across 35 pages) but takes n

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

Aggressive MCP rate-limiting with no Retry-After/scope/quota signal; spaced-out retries appear to extend the lockout window

Summary

MCP calls hit rate limiting after roughly 4 calls, with a lockout lasting minutes, and:

  • No Retry-After header or equivalent field in the error response.
  • No indication of what's being rate-limited (per-tool? per-workspace? per-token?) or what the quota actually is.
  • Retrying with sensible spaced-out backoff appears to extend the lockout window rather than let it expire — i.e. correct client backoff behavior is punished instead of rewarded.

All 5 independent audit probes hit

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

Worker management tooling gaps: no workers_delete despite can_delete:true, no pause/disable, workers_versions empty after edits, workers_write_file silently drops omitted files

Summary

Four related gaps/bugs in worker management via MCP:

  1. No workers_delete tool — the worker data model reports can_delete: true, but no MCP tool exists to actually delete a worker.
  2. No pause/disable — workers_update rejects both enabled and trigger_type: disabled as a way to pause a worker without deleting it.
  3. workers_versions returns empty after edits — after editing a worker (e.g. via workers_write_file), workers_versions shows no version history, so

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

Context management tooling gaps: no delete, no file/path listing inside a context, and contexts_versions returns empty despite being git-versioned

Summary

Three related gaps in context (worker memory) tooling via MCP:

  1. No delete tool — no MCP tool exists to delete a context or a file within a context. Test/scratch contexts accumulate with no cleanup path.
  2. No file-tree/listing tool — contexts_list only returns folder-level metadata (the contexts themselves), not the files/paths inside a given context. Without already knowing exact filenames, files inside a context are undiscoverable via MCP.
  3. **contexts_versions returns

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

No approve/reject MCP tool — approvals can be listed but not acted on via MCP

Summary

approvals_list exists and returns pending approvals, but there is no approvals_approve / approvals_reject (or equivalent) MCP tool. Verified against the full tool catalog — no action tool exists. HITL (human-in-the-loop) approval flows are therefore listable via MCP but not actionable; approving/rejecting requires switching to the human dashboard UI.

Repro

  1. approvals_list() → returns pending approval(s).
  2. Search MCP tool catalog for an approve/reject/resolve tool → non

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

contexts_read returns 500 Internal Server Error on every existing file (write succeeds, read of the same path crashes)

Summary

contexts_write succeeds and reports the correct size, but an immediate contexts_read of that exact same path returns {"detail":"Internal server error"} (HTTP 500). Reproduced across plain-text and unicode content, across 2 different contexts. Reading a genuinely-missing path works correctly and returns "Context file not found" (expected 404-style behavior) — so the read path specifically crashes on hits and only works on misses. This makes worker memory (contexts) effectively wr

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

Approval-gated runs vanish from MCP: run_id from workers_run never resolves via runs_get/runs_list/runs_cancel

Summary

Running an approval-gated worker (outbound-approval-demo) via workers_run returns a run_id, but that run_id never resolves through runs_get, runs_list, or runs_cancel — all return "Run not found". workers_get on the same worker shows last_run: null, recent_runs: [], i.e. the run is invisible everywhere in the MCP surface. This makes the HITL (human-in-the-loop) approval loop completely unobservable via MCP.

Repro

  1. workers_run on outbound-approval-demo → retur

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

MCP: file-input workers unrunnable — workers_sample_input returns inline text, workers_run rejects it, no upload tool exists

Summary

Workers with a type:file input (e.g. document-drafter's source_materials) cannot be run end-to-end via MCP. workers_sample_input returns inline text content for the file input, but workers_run rejects that same value with "value must be a SHA-256 reference from /uploads". No MCP tool exists to upload a file or mint a /uploads SHA-256 reference, so the sample the API itself hands back is guaranteed to fail validation.

Repro

  1. workers_sample_input on `document-drafter

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

Expose worker standalone share links in CLI and MCP

Problem

Floom already has the worker standalone sharing backend and web surface:

  • POST /workers/{worker_id}/share-link mints revocable /s/<token> links.
  • /s/<token> renders the standalone share page.
  • POST /workers/import-from-share imports shared workers.
  • The web worker Share modal calls api.workers.shareLink(w.id).

Agents and CLI users still had no direct way to mint those links. The visible worker CLI/MCP surface exposed workers list, workers get/show, workers run,

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

Agent-native secret provisioning: secrets.request (user pastes key, agent never sees it)

Problem

Agents (Claude/Cursor/Devin/etc.) hesitate to call secrets.set with a raw key value because it trips their "never enter API keys into a field" safety reflex. We're mitigating with wording (PR #2049 relabels the tool + adds MCP server instructions), but the universally-safe pattern is to let the agent provision a secret it never touches.

Proposal — secrets.request

New MCP tool + flow, mirroring how password managers / OAuth let an agent trigger a credential entry it never

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

Post-launch: add agent aliases for API, CLI, and MCP

Context

We explored a phase-2 rename surface for the post-launch agent terminology work: expose agent-facing API/CLI/MCP aliases while keeping the runtime, DB, manifests, and worker.yml contract unchanged.

Given we are close to launch, this should be parked. Adding new public aliases now changes behavior at several edges and could create unexpected compatibility or auth/routing regressions.

Principle

Do not hard-rename the runtime. Keep these stable for now:

  • Database tables and colu

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

P0: Env-token CLI cannot infer active workspace for MCP install

Launch blocker

With a cloud API token supplied only through environment variables, workspace listing works but the active workspace is not inferred for commands that need it.

Repro

Environment:

WORKEROS_API_BASE=https://workeros-api.floom.dev
WORKEROS_API_TOKEN=<cloud PAT>

This works and returns the accessible workspace plus active_id:

floom workspaces list --json
# workspaces: [{ id: ws_7ff0773b15684f, name: vbellala, ... }]
# active_id: ws_7ff0773b15684f

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

MCP install modal: long cloud config overflows panel

Context

  • Federico flagged visual misalignment in the Agent install card/modal.
  • Screenshot reference: Screenshot 2026-06-24 at 18.14.50.png.
  • This lives upstream in components/mcp/McpInstallPanel.tsx, rendered by components/mcp/McpInstallModal.tsx and Settings.

Observed

  • In the web-app modal, the long https://workeros-api.floom.dev/mcp/... URL visually runs beyond the panel area.
  • The app modal and settings reuse McpInstallPanel, so the fix belongs in the engine repo.

Expected

Read the thread · 2026-06-25 · closed · 1 comment

MCP install: add clearer token path from Agent install surface

Context

  • Federico noted the web app Agent install surface also needs a token link or equivalent.
  • Current shared component: components/mcp/McpInstallPanel.tsx.

Observed

  • The panel has a browser-local "Create key" action and explanatory text about rotating in Settings → Connect & automate.
  • There is no explicit link or deep navigation to token management from the install surface.

Expected

  • Agent install gives users an obvious path to create, inspect, or rotate the token used by the MCP c

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

MCP install modal: replace letter-in-box placeholders with real client logos

Bug

On the MCP install modal (McpInstallPanel, sidebar MCP popup + Settings → Agent install), the supported-clients grid renders letter abbreviations inside bordered square boxes instead of real brand logos.

DOM: div.grid.grid-cols-2.gap-2.sm:grid-cols-3 with aria-label="Supported MCP clients"

Visible text: C Claude > Cursor CX Codex {} VS Code W Windsurf CL Cline

Expected: Real brand logos for Claude, Cursor, Codex, VS Code, Windsurf, Cline — clean SVG marks with

Read the thread · 2026-06-24 · open · 0 comments

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