GET /api/companies/{id}/issues?parentIssueId=<id> ignores the filter

[InsightStream-Dev]

Paperclip API: parentIssueId query parameter is ignored

Affects: Paperclip (local install at http://127.0.0.1:3100, version unknown — please advise on how to determine)
Discovered: 2026-04-16, during Session 9 of InsightStream AI multi-agent project
Severity: Medium — agents waste tokens working around it; primary safeguards still hold but secondary protection is lost

Summary

GET /api/companies/{companyId}/issues?parentIssueId=<id> silently ignores the parentIssueId query parameter and returns the full company-wide issue list.

Reproduction

1. As a CEO-type agent in a Paperclip company, receive a parent issue (call it INS-81).
2. Create a sub-issue with parentId set to that parent (e.g., delegated to a specialist).
3. Issue:

   GET /api/companies/<companyId>/issues?parentIssueId=<parent-id>
   

4. Expected: response contains only the sub-issues whose parent is <parent-id>.
5. Actual: response contains all active issues in the company, regardless of parent.

Diagnostic evidence

CEO agent's own real-time observation during a delegation flow:

"I tried to filter by my parent issue ID, but the file shows different parent IDs—it seems there aren't actually any sub-tasks for my task. […] The parentIssueId query parameter isn't actually filtering the results — I'm getting back issues with different parent IDs."

The agent worked around the issue by reasoning about the freshness of the parent task, but this consumed several extra LLM turns and tokens that a working filter would have avoided.

Impact

• CEO agents that follow the recommended duplicate-prevention pattern (fetch sub-tasks for current parent, skip if a sub-task with same assignee exists) cannot rely on this endpoint.
• Workaround forces fetching all active issues and filtering client-side, which:
  • Increases token consumption per CEO heartbeat (transferring + reasoning over irrelevant issues)
  • Scales poorly as company issue count grows
• Primary protection against duplicate sub-tasks still holds (parent-task blocked status + checkout 409s), so this is not a correctness blocker today — but it removes a layer of defense.

Workaround (in use)

CEO agent's AGENTS.md updated to fetch by status only and filter client-side:

GET /api/companies/<companyId>/issues?status=todo,in_progress,blocked

…then filter the response in-process for parentIssueId === <parent-id>.

Suggested fix

Either:

• Honor the ?parentIssueId= query parameter on the issues list endpoint, or
• Provide an explicit GET /api/issues/<parent-id>/children endpoint and document it as the canonical sub-task lookup.

Environment

• OS: Windows 11 (also affects Linux WSL — not OS-specific)
• Paperclip endpoint: http://127.0.0.1:3100
• Auth: bearer token via PAPERCLIP_API_KEY
• Adapter type for affected agents: claude_local

[serenakeyitan]

null