Reported issues for ProAgentStore

Pod holds 24 of 209 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 ProAgentStore.

Most discussed

coding_timeline records no per-step token, cost, files-changed or test-result summary — the ordering half of this is fixed

coding_timeline is the only MCP-side window into what a coding session is actually doing, and it shows one half of the conversation.

Observed on session csess_42bdfe20-ca10-4172-90af-14114b70b28c (issue #672 implementation run). Every event returned was type command or brain — the instructions going into the coding engine. Sample:

seq 9077, type brain — "AI run started — objective: ..."
seq 9078, type command — "Let's start by exploring the repository structure..."
seq 9084, ty

Read the thread · 2026-08-16 · closed · external user · 8 comments

The MCP server never publishes tool annotations or output schemas — it already classifies every tool read/write/destructive and tells no host

The MCP server withholds two things the spec has for it, and it already knows both

The owner connected ProAgentStore to ChatGPT. It works — all 135 tools registered with their input schemas, OAuth used, Developer Mode on, Connected 14 Aug 2026. But ChatGPT's settings page flags every single tool with "Output schema recommended", and its permission control reads "Allow low-risk actions" with no way to tell which actions are low-risk.

Both are spec features PAGS does not use. Ve

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

[bug] repo_read_file caps at 8KB of the 64KB the runner already read, with no offset to fetch the rest — the root cause under #522's repeated "read the full file"

`repo_read_file` throws away 87.5% of what the runner already read, and there is no way to ask for the rest

Live, on the owner's Heartfull Repo Coder (f8ddc272…), 2026-08-12 08:49:34Z. He asked why users joining an event get Cloud Firestore permission denied. The agent's own words:

"The rules file was truncated at 8192 bytes and the eventCalls rule is at line 511 — well past the cut-off. Let me fetch that section directly."

It then recovered by using repo_grep to locate `fi

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

[bug] The Pilot overrode the engine's correct objection and reported it to the owner as his own explicit choice — the deploy it broke was never his decision

The Pilot overrode the engine's correct objection, then told the owner he had chosen it

Production, instance f8ddc272… (Heartfull, Repo Coder), 2026-08-11 22:37:35 UTC. The Loop complete message told the owner:

*"app/pubspec.yaml bumped from 1.0.127+133 to 1.0.127+134 per explicit user instruction. … The user was warned that admin/pubspec.yaml should be bumped instead (since admin/** changed), but explicitly chose to bump app/pubspec.yaml and proceed. The version

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

[bug] The tmux Operator promises to fetch GitHub issues it has no tool to reach — the CONNECTED TOOLS list is never stated to be exhaustive

The owner asked for GitHub issues four times, and got three turns of "tell me the repo and I'll fetch them"

Live conversation on Heartfull (tmux) (cda75e28-cace-4958-ac3e-6a7528e6b719, agent tmux-operator), 2026-08-10 22:46–22:50 UTC. The owner's machine was off, so the runner was down. Verbatim, from agent_trace:

22:47:16 owner — "Can you check tickets for now? If you can't connect to the machine, at least you should be able to get the tickets and understand if it was close

Read the thread · 2026-08-10 · closed · outside contributor · 7 comments

[bug] The capability-constraint gate opens when there is no authority, refuses a target its own ceiling permits, and no agent declares targets:"single"

Three residuals from #404 and #402 — the ceiling opens when there is no authority, refuses a target it permits, and is declared by nobody

#404 shipped the capability-constraint gate and #402 added the binding half. Both are live and both are right in the case they were built for. Three things sit just outside their acceptance lists.

1. The gate is SKIPPED when there is no authority — the opposite of every neighbouring gate

workers/api/src/lib/tool-registry.ts:467-486:

if (

[Read the thread](https://github.com/ProAgentStore/platform/issues/441) · 2026-08-08 · closed · outside contributor · 8 comments

### [bug] lead_finder cannot sweep a capital city: raw addressComponents push the flatten step's journal entry over the 1MiB Workflow limit

## `lead_finder` cannot sweep a capital city: the raw `addressComponents` arrays make the flatten step's journal entry exceed 1MiB

Three `pipeline-run` errors, all on instance `933ebec5…`, read back today via `list_errors`:

2026-08-03 08:08 pipeline "lead_finder" crashed: WorkflowInternalError: Step s3-flatten-1 output is too large. Maximum allowed size is 1MiB. 2026-08-03 06:49 pipeline "lead_finder" crashed: WorkflowInternalError: Step s4-map-1 output is too large. Maximum allowed si

Read the thread · 2026-08-07 · open · outside contributor · 12 comments

[3P] Tier-1: declarative agent schema + open tool catalog + shared runtime

Part of the open-to-third-party program (epic to follow).

Goal: a third party defines an agent as pure declarative config — no platform PR.

Formalize the declarative agent definition (extend `agents.config`): identity, prompt, guardrails, model, `tools[]`, `surfaces[]`, `runtime`, `settingsSchema`. Versioned.
Open the capability vocabulary. Today `AgentSurface`/`workflow` in `lib/agent-capabilities.ts` are hardcoded closed unions → any new agent shape needs

Read the thread · 2026-08-01 · closed · outside contributor · 6 comments

Most recent

No live, per-step trace of an in-flight loop run over MCP — only `coding_loop_status` and a post-hoc `detail`

The gap

Owner feedback (instance bd43f4de, 2026-08-15): there is no real-time, per-step observability into a running coding/agent loop from an external MCP client. While a run is in flight the only signal is coding_loop_status (status, iteration, lastProgressAt, and — once finished — a one-line detail). There is no way to see what the agent is actually doing mid-run: no per-iteration tool calls with their inputs/outputs, no reasoning, no partial output, no streaming progress. `i

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

A stored .docx contributes nothing — extractFileText handles text and PDF only, so read_file and RAG see an empty document (and .doc is a different, harder problem)

The problem

A .docx that reaches the file store is invisible to the agent. read_file refuses it, search_knowledge cannot retrieve from it, and the console shows a file with no content. The agent can say "there is a file called X" and nothing else about it.

That is the first wall in #756: the user's emailed club form arrives, gmail_download_attachment stores it (once #755 is fixed), and the agent still cannot tell the user a single thing the form asks for.

**Priority — `P2: correctn

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

Every MCP tool call from an external client fails once with "has not been loaded yet" and succeeds on an identical retry — the error lists back the exact parameter names it was sent as possibly incorrect

Promoted from feedback rows b7b6c751-8ecd-43dd-86d0-d653ec9e8cbd and a0666f22-b36f-40c4-b7f0-bc879f9cdd2b, where this was recorded twice as a minor note (2026-08-15 and 2026-08-17). Both still status: open, issue_url: null. Still reproducing on 2026-08-24.

What happens

A first call to a PAGS MCP tool from an external client fails with either:

`'mcp_..._coding_loop_start' has not been loaded yet. You do not have the correct parameter names for this tool. Valid input schema: {...}.

Read the thread · 2026-08-24 · open · external user · 1 comment

gmail_download_attachment refuses the id gmail_read_message just handed the model — the validation re-fetch is what fails, and the download endpoint never needed the round-trip

What the user saw

A Gmail-enabled agent read a message, saw its attachments, and could not download either of them.

Instance e17d538d-6940-4773-80f6-3715c1b2d2fa, message 1a00cff038273010
Subject: Fwd: Urgent Please Read - Hawthorn Tennis Tennis Club Summer Competition Form and Junior Club Champs Forms Attached- Thanks Kelly
gmail_download_attachment returned That message has no attachment with id <id>. It has: <the same two filenames with different opaque ids>
Retrying wi

Read the thread · 2026-08-23 · closed · external user · 5 comments

A webhook trigger's payload becomes a task in the system prompt, unfenced and labelled (user-set) — assignedBy has no value for "a stranger", so third-party text is stamped as the owner's standing instruction

Part of the ingress enumeration behind #746–#752. This one is the worst-placed of the set: the untrusted text does not land in a tool result, it lands in the system prompt — and it arrives wearing a label that tells the model to rank it above its own judgement.

The problem, from the owner's position

The owner wires a webhook trigger with action create_task — the documented way to let Zapier, a form, a monitoring service or a partner system put work on an agent's list. Third-party text

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

An owner cannot read what their MCP clients are told — SERVER_INSTRUCTIONS and platform_guide are reachable from no URL, and the published paraphrase already drifted in the commit that changed them

Problem

An owner connects Claude Code, Codex or Cursor to mcp.proagentstore.online/mcp and their client is immediately handed two documents that shape everything it does: the server instructions string delivered at initialize, and whatever platform_guide returns when the model calls it.

The owner cannot read either one without a checkout. Not from the console, not from the API, not from a URL. So when a client behaves oddly — refuses a capability, reaches for the wrong tool — th

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

Record ADR 0006 — text the platform did not author is fenced — and replace the four-name pin-list guard with a per-tool declaration the compiler enforces

The parent of #746, #747, #748, #749, #750, #751 and #725. Each of those is a place where attacker-authorable text reaches the model without the fence. None of them is a mistake anyone made carelessly — every one is a file where a careful author reasoned about the right things and the fence was not among them, because nothing on the platform says which texts need it or fails when one is missed.

The evidence that the coverage was never enumerated

#308 fixed fetch_url, `http_reque

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

repo_read_file, repo_git and the terminal capture tools return the owner's machine unfenced — the Co-pilot already calls this content untrusted, the chat path does not

Part of the ingress enumeration behind #725, #746, #747, #748, #749, #750. This is the family reached over the runner relay: text from the owner's own machine that the owner did not write.

Why this is untrusted, in the platform's own words

Two places in this repo already say so:

lib/retrieval.ts:136 names repo files as untrusted when the same content arrives via RAG:
```
return context ? fenceUntrusted(context, "documents/URLs/repos/webhooks") : "";
```
`lib/coding-co

Read the thread · 2026-08-23 · closed · outside contributor · 4 comments

The pipeline binder strips the untrusted fence for $ref and ai_generate never puts it back — the shipped site-builder renders Google-listing and web-search text into a model prompt bare

Part of the ingress enumeration behind #725, #746, #747, #748, #749. This one is different in kind: the fence is applied, correctly, at the source — and then removed on purpose, and never put back before the text reaches a model.

The problem, from the owner's position

A pipeline calls an API or a web search, reshapes the result, and asks the owner's BYOK Claude to write something from it. The connector fenced that remote text (#308). By the time it reaches the model it is bare. The ship

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

mcp_call_tool returns a remote server's payload unfenced, and mcp_get_prompt puts 1000 chars of server prose outside its own fence — in the file that wrote the fencing rule down

Part of the ingress enumeration behind #725, #746 and #747. This one is contained entirely within lib/connectors/mcp.ts, which is the file that wrote the rule down.

lib/connectors/mcp.ts:908-913 states it:

FENCING. resources/read and prompts/get return remote text straight onto the model's instruction path — the same hazard the platform already fences for RAG in agent-think.ts. So both wrap their payload with fenceUntrusted … An unfenced resource read is prompt injection with a

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

search_knowledge / read_knowledge / read_file return the same corpus the RAG block fences — the two paths are 40 lines apart in retrieval.ts and only one is fenced

Part of the ingress enumeration that #725 and #746 come from. This one is the sharpest of the set, because the fenced path and the unfenced path are 40 lines apart in the same module, over the identical corpus.

The problem, from the owner's position

Repo Chat indexes a GitHub repo into the instance's vector store. The owner asks a question. Two things can happen:

The chat turn's automatic RAG block retrieves the same chunks → they arrive fenced, and the model is told never to obe

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

GitHub issue and PR bodies reach the model unfenced — text any stranger can author on a public repo, on 22 of 42 live instances, one of which also holds a consented shell

Found while enumerating every ingress of text the platform did not author, after #725 turned up a miss that #308's fix had walked past. #308 named three tools and fixed three tools; nothing enumerated the rest. This is one of the rest.

The problem, from the owner's position

An agent is asked "what's issue #412 about?". It calls github_read_issue, and the issue body — which any GitHub account on the internet can author on a public repo — arrives in the model's transcript as plain t

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

External MCP agents cannot discover internal agent connector capabilities, so they drive coding terminals instead of calling instance tools

Summary

When an external MCP client/agent is using the ProAgentStore MCP server to work with a PAGS agent instance, it does not have an obvious, reliable path to discover what the target internal agent instance can do. In the observed case, Claude was chatting with the user through PAGS MCP about the FIS coder. It needed to list GitHub issues for the FIS repository, but concluded it had no direct GitHub issue access and instead drove the coding session terminal, asking Codex on the user's Ma

Read the thread · 2026-08-23 · closed · external user · 4 comments

The MCP operator skill is in no gate's input set — it hand-lists 33 of 145 tools and never mentions the `confirm` gate 6 of them require

Found while assessing #739, which names the operator skill as one of the three nearest homes for per-instance operator prose. The skill is the right audience for the global half of that job — and it is the one operator-facing artefact in this repo that no gate reads.

What an operator gets

skills/proagentstore-mcp-operator/SKILL.md is the canonical skill (4,024 bytes), copied verbatim into plugins/codex/proagentstore/skills/…/SKILL.md and `plugins/claude/proagentstore/skills/…/SKIL

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

An instance has one instructions box and it is wired to "obey", so guidance for the CALLER driving it has nowhere to live

Analyst pass 3, 2026-08-23 — rewritten to a DECIDED design. The prior pass established the shape (a per-instance document, rendered-not-stored live context, no generator). This pass makes the two calls it left open and departs from the brief in two places, with measurements: the manual is not injected into the prompt body (measured cost below), and it is one read surface over two stores, not one record. Verified/inferred labelled throughout; every coordinate re-derive

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

[Epic] Codex as a first-class structured engine (parity with Claude)

Make Codex (and, later, other CLIs) a first-class coding engine on par with Claude: driven through its own structured event stream instead of scraped raw stdout, with the same clarity Claude already has about how it's invoked and who pays. Today Claude is the only structured engine (mode = clientType === "claude" ? "stream-json" : "raw" in headless.ts); every other engine is spawned raw, so its output is noisy/truncated, its spend is unmetered, and its acts are unattributed.

The

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

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

Reported issues for ProAgentStore

Most discussed

coding_timeline records no per-step token, cost, files-changed or test-result summary — the ordering half of this is fixed

The MCP server never publishes tool annotations or output schemas — it already classifies every tool read/write/destructive and tells no host

The MCP server withholds two things the spec has for it, and it already knows both

[bug] repo_read_file caps at 8KB of the 64KB the runner already read, with no offset to fetch the rest — the root cause under #522's repeated "read the full file"

repo_read_file throws away 87.5% of what the runner already read, and there is no way to ask for the rest

[bug] The Pilot overrode the engine's correct objection and reported it to the owner as his own explicit choice — the deploy it broke was never his decision

The Pilot overrode the engine's correct objection, then told the owner he had chosen it

[bug] The tmux Operator promises to fetch GitHub issues it has no tool to reach — the CONNECTED TOOLS list is never stated to be exhaustive

The owner asked for GitHub issues four times, and got three turns of "tell me the repo and I'll fetch them"

[bug] The capability-constraint gate opens when there is no authority, refuses a target its own ceiling permits, and no agent declares targets:"single"

Three residuals from #404 and #402 — the ceiling opens when there is no authority, refuses a target it permits, and is declared by nobody

1. The gate is SKIPPED when there is no authority — the opposite of every neighbouring gate

[3P] Tier-1: declarative agent schema + open tool catalog + shared runtime

Most recent

No live, per-step trace of an in-flight loop run over MCP — only coding_loop_status and a post-hoc detail

The gap

A stored .docx contributes nothing — extractFileText handles text and PDF only, so read_file and RAG see an empty document (and .doc is a different, harder problem)

The problem

Every MCP tool call from an external client fails once with "has not been loaded yet" and succeeds on an identical retry — the error lists back the exact parameter names it was sent as possibly incorrect

What happens

gmail_download_attachment refuses the id gmail_read_message just handed the model — the validation re-fetch is what fails, and the download endpoint never needed the round-trip

What the user saw

A webhook trigger's payload becomes a task in the system prompt, unfenced and labelled (user-set) — assignedBy has no value for "a stranger", so third-party text is stamped as the owner's standing instruction

The problem, from the owner's position

An owner cannot read what their MCP clients are told — SERVER_INSTRUCTIONS and platform_guide are reachable from no URL, and the published paraphrase already drifted in the commit that changed them

Problem

Record ADR 0006 — text the platform did not author is fenced — and replace the four-name pin-list guard with a per-tool declaration the compiler enforces

The evidence that the coverage was never enumerated

repo_read_file, repo_git and the terminal capture tools return the owner's machine unfenced — the Co-pilot already calls this content untrusted, the chat path does not

Why this is untrusted, in the platform's own words

The pipeline binder strips the untrusted fence for $ref and ai_generate never puts it back — the shipped site-builder renders Google-listing and web-search text into a model prompt bare

The problem, from the owner's position

mcp_call_tool returns a remote server's payload unfenced, and mcp_get_prompt puts 1000 chars of server prose outside its own fence — in the file that wrote the fencing rule down

search_knowledge / read_knowledge / read_file return the same corpus the RAG block fences — the two paths are 40 lines apart in retrieval.ts and only one is fenced

The problem, from the owner's position

GitHub issue and PR bodies reach the model unfenced — text any stranger can author on a public repo, on 22 of 42 live instances, one of which also holds a consented shell

The problem, from the owner's position

External MCP agents cannot discover internal agent connector capabilities, so they drive coding terminals instead of calling instance tools

Summary

The MCP operator skill is in no gate's input set — it hand-lists 33 of 145 tools and never mentions the confirm gate 6 of them require

What an operator gets

An instance has one instructions box and it is wired to "obey", so guidance for the CALLER driving it has nowhere to live

[Epic] Codex as a first-class structured engine (parity with Claude)

The

`repo_read_file` throws away 87.5% of what the runner already read, and there is no way to ask for the rest

No live, per-step trace of an in-flight loop run over MCP — only `coding_loop_status` and a post-hoc `detail`

The MCP operator skill is in no gate's input set — it hand-lists 33 of 145 tools and never mentions the `confirm` gate 6 of them require