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/cotal-actions-cotal-ai/issues.md or /mcp/cotal-actions-cotal-ai/issues.json, or Pod over MCP.

Reported issues for COTAL actions (cotal.ai)

Pod holds 15 of 15 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to COTAL actions (cotal.ai).

Most discussed

connector-jcode: repeated subagents leak MCP bridge children until seat teardown

Summary

A long-running Jcode seat accumulated one sleeping connector-jcode/dist/mcp.js child per repeated subagent/swarm lifecycle. The children remained alive after the subagent work ended, growing the private process tree and resident memory while the mesh seat still appeared healthy.

Measured incident

On 2026-08-24, fm-hotupdate-4 ran Jcode 0.78.1-dev with a private Cotal MCP bridge. Before its managed stop, the exact seat-owned tree contained:

Read the thread · 2026-08-24 · closed · outside contributor · 5 comments

MCP cotal_spawn has no manager-selection contract — in a multi-manager space placement is a coin flip

Summary

cotal_spawn over MCP carries no way to say WHERE the seat should run. In a space with more than one manager, the spawn request anycasts and whichever manager wins the queue hosts the seat — so placement is effectively random from the caller's point of view.

Why it matters

Seats are usually placed for a reason the request cannot currently express: a worktree that exists on exactly one machine, a toolchain installed on one box, locality to the artifact being graded. Today (a…

Read the thread · 2026-08-13 · open · outside contributor · 4 comments

MCP cotal_spawn has no instance parameter, so an agent cannot pin a spawn and always draws the class anycast

The MCP cotal_spawn tool exposes no instance parameter, so a caller going through it cannot pin a spawn to a chosen manager and always draws the class anycast.

Its full parameter set:

name, agent, model, variant, role, cwd, launchOptions

No on, no instance, no host. The CLI equivalent has --on <instance> (with --detach), and its own help states the default is class anycast. So the two surfaces disagree about whether pinning is expressible at all.

Why this matters…

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

security: manager spawn contract exposes events/transcript to any spawn-capability caller with no admin-tier check

Summary

The manager's typed spawn contract admits a caller-controlled events: boolean, and opStart arms it — mutating the child's publish grant and setting COTAL_EVENTS — with no operator/admin-tier check. Any holder of an ordinary spawn capability can therefore cause a spawned agent's harness session output to be published to a channel other principals can read.

This is an authority question rather than a behaviour one: it changes who can cause host-session disclosure, not…

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

connector-jcode: the mandatory readiness turn races the MCP bridge, refusing healthy seats

Summary

A jcode seat's mandatory readiness turn races the MCP bridge connection. The host dispatches the readiness turn immediately at spawn; jcode locks its tool snapshot for the turn before MCP: Connected to 'cotal' lands, so the first turn runs with no cotal tools, completes with no tool call, and the host refuses to advertise the seat (cotal MCP bridge did not become callable…). The seat process is healthy; the refusal is pure ordering.

Evidence (installed connector, one…

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

channelHistory silently returns [] when consumer-create is denied - non-admin observers see an empty channel instead of an error

Predicted-from-source (live repro pending — needs one non-admin call against an auth-mode broker)

CotalEndpoint.channelHistory (endpoint.ts:1673-1700) builds a throwaway JetStream consumer; the catch around it is commented in the source itself — "stream missing or consumer create denied (non-admin)" — and then return msgs with whatever was collected: an empty array.

A normal channel read ACL does not grant CONSUMER.CREATE, so any non-admin observer holding a legitimate read grant…

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

connector-claude-code: CLAUDE_PROVIDER_KEYS forwards the Bedrock/Vertex selection flags but none of the credentials they require

Summary

connector-claude-code's CLAUDE_PROVIDER_KEYS allowlist forwards the provider selection flags (CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX) but none of the credentials those flags require. A managed Claude seat on Bedrock or Vertex therefore cannot authenticate from environment, and the failure presents as a provider or auth problem rather than a connector one.

Shipped in the installed @cotal-ai/connector-claude-code v0.40.0.

Measured

Sentinel values for…

Read the thread · 2026-09-03 · closed · outside contributor · 1 comment

connector-jcode: when soft interrupts time out, the automatic queue has no fallback drain and mimics a wedge on a healthy seat

Summary

When a Jcode seat's soft interrupts time out, the connector-owned automatic queue has no fallback drain and grows without bound. The seat stays healthy and productive throughout, and cotal ps renders the growing queue in a way that is indistinguishable from a wedge.

This is not #1080 (a restart stranding DMs on a dead lifecycle) and not the active-turn stall that PR #1079 fixed. It is the case where PR #1079's own remedy fails: that fix routes directed traffic through Jcode…

Read the thread · 2026-09-03 · open · outside contributor · 1 comment

Most recent

connector-jcode: a seat with a heavy persona works invisibly inside an unbounded readiness turn, unreachable and killable at the gate

A managed jcode seat can be alive, healthy, and doing exactly the work it was given while having no mesh presence at all. It is absent from cotal_roster, and cotal_dm to it fails with no peer "<name>" in space "<space>". It is not deaf, not hung, and must not be restarted. It is executing inside its readiness turn, which has no deadline.

Observed

rev1211-test, a review seat spawned 2026-09-03 with a long persona, spent roughly 13 minutes in this state before joining.…

Read the thread · 2026-09-03 · closed · outside contributor · 1 comment

connector-jcode: cotal_inbox advertises peek then rejects every argument

Summary

The Jcode connector advertises cotal_inbox with the core tool's optional peek argument, then rejects every inbox argument before relaying the call. Jcode therefore emits a schema-valid peek:false and receives:

Error: cotal_inbox: unknown argument(s): peek — this tool takes no arguments

A literal zero-argument relay call succeeds. This blocks ordinary Jcode agents from completing inbox preflight unless they know to ignore the exposed schema and omit the argument…

Read the thread · 2026-08-24 · closed · outside contributor · 0 comments

orientation during pre-join readiness poisons the session: seat later claims it is not connected

A jcode seat's mandatory readiness turn calls cotal_orientation BEFORE agent.start() (host.ts: readiness at ~341, start at ~372). tool-specs.ts prefixes the card with "(not connected to the mesh yet — the live context below is empty)" whenever agent.connected is false — truthful at that instant, but the line stays in the session context. Asked later "are you connected?", the model quotes the stale readiness card and answers NO even though presence shows the seat idle on the roster and live…

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

Foreground 'cotal spawn --transcript' never grants publish on tr- - silent empty transcript in auth mode

Predicted-from-source (live repro pending — needs an auth-mode broker + foreground spawn)

transcriptChannel is never called anywhere in implementations/cli:

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

manifest prompt: on a connector that ignores prompts should surface at deploy preflight

The connector contract (core LaunchOpts.prompt) says only connectors that support an auto-submitted first prompt (today: Claude Code) deliver it; others ignore it. With per-agent prompt: now in the mesh manifest, that silent ignore becomes a declarative-surface footgun: a manifest can declare a kickoff for an OpenCode/Hermes agent and the deploy succeeds with the prompt silently dropped — observed live with an OpenCode agent whose prompt: never fired.

Model variants already have the…

Read the thread · 2026-07-28 · open · outside contributor · 1 comment

claude-connector: concurrent spawns share one ~/.claude/.credentials.json, race on OAuth refresh (cascading logouts)

Problem

Every claude-connector agent spawned by Cotal shares the same ~/.claude/.credentials.json on its host machine (confirmed in connector-claude-code: comment says "claude auths via macOS Keychain / an OAuth token... The OS allow-list (PATH/HOME/TERM/...) is the only thing inherited" — HOME is passed through unmodified, so every spawn reads/writes the same Keychain entry / credentials file as every other spawn on that machine, and as any manually-run claude).

Claude Code's…

Read the thread · 2026-07-20 · closed · external user · 1 comment

Managed agents hang at starting… on Claude 2.1.178 — new --dangerously-load-development-channels warning isn't auto-cleared

Summary

Managed agents never join the mesh on Claude Code ≥ 2.1.178 — they sit at starting… forever and never register presence. Root cause: Claude changed the --dangerously-load-development-channels confirmation screen, so the manager's pty auto-confirm no longer clears it and the session hangs before the cotal channel/MCP ever loads.

What changed in Claude

The connector launches claude --dangerously-load-development-channels <ref> and the manager's pty runtime auto-clears…

Read the thread · 2026-06-16 · closed · outside contributor · 1 comment

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