Project Orchestrator
ReviewAudited by ClawScan on May 10, 2026.
Overview
Project Orchestrator appears purpose-built for coordinating coding agents, but it exposes unauthenticated local services and tools that can index and persist project code and shared agent context.
Treat this as a powerful local development service rather than a simple prompt-only skill. Install it only in a trusted environment, change default credentials, avoid exposing its ports, sync only approved project directories, and review/pin dependencies before building.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Anyone who can reach the API may be able to view or change orchestrator data, trigger indexing, or delete stored project/workspace records.
The documented REST API includes project, workspace, task, sync, watch, and delete endpoints, so lack of authentication is a material permission-boundary issue if the service is reachable by other local users, containers, or the network.
Currently, the API does not require authentication. For production deployments, implement authentication at the reverse proxy level.
Run it only on a trusted local interface, add authentication or a reverse proxy before any shared deployment, and avoid exposing port 8080 beyond your machine.
Private indexed project information could be reachable through Neo4j or Meilisearch if these ports are exposed on a shared or networked machine.
The database and search services are published to the host with documented default credentials/keys, increasing the chance that stored code metadata, plans, and decisions are accessible outside the intended agent workflow.
ports: - "7474:7474" - "7687:7687" ... - NEO4J_AUTH=neo4j/orchestrator123 ... - MEILI_MASTER_KEY=orchestrator-meili-key-change-me
Change the default passwords/keys, bind services to localhost where possible, and restrict access with firewall rules or Docker network settings.
Sensitive code structure, decisions, or notes may be stored long-term and reused by other agents; incorrect or maliciously inserted context could influence later work.
The skill intentionally persists local code structure and shared context for reuse by multiple agents. The provided artifacts do not clearly define exclusions, retention, review, or poisoning safeguards for that shared memory.
**Shared Knowledge Base** — Code structure stored in Neo4j graph database, accessible to all agents ... **Auto-Sync** — File watcher keeps the knowledge base updated as you code
Sync only intended repositories, exclude secrets and private files, periodically review/delete stored notes and indexes, and treat retrieved shared context as advisory rather than authoritative.
An agent with access to these tools could delete orchestrator records, start background watching, or index a directory beyond what the user expected.
The MCP surface includes mutating and broad local-indexing tools. These are aligned with the orchestrator purpose, but the provided artifacts do not show per-action approval, dry-run, or path containment controls.
`delete_project`, `sync_project` ... `sync_directory`, `start_watch`, `stop_watch`, `watch_status`
Use the MCP server only with trusted agents, require confirmation for delete/sync/watch actions, and register only explicitly approved project paths.
Future installs could build against changed upstream code, affecting behavior or security without an obvious version change in this skill.
Cargo will fetch this dependency from a git repository without a pinned revision in the provided manifest, so builds may incorporate code that differs from what was reviewed.
nexus-claude = { git = "https://github.com/this-rs/nexus.git", features = ["memory"] }Pin git dependencies to a specific commit, include a lockfile for reproducible builds, and review dependency updates before rebuilding.
One agent or process could potentially claim tasks, mark work complete/failed, or send wake events as another agent, confusing coordination state.
Agent identity and completion signaling appear to be represented by plain API fields/webhooks. Combined with the documented unauthenticated API, this leaves unclear origin and permission boundaries between agents.
PATCH /api/tasks/{task_id}
{"status": "in_progress", "assigned_to": "agent-id"}
...
POST /api/wake
{
"task_id": "uuid",
"success": false,
"summary": "Tests failing after X modification"
}Add authenticated agent identities or trusted local-only controls before using this with multiple independent agents or team members.