Dangerous exec
- Finding
- Shell command execution detected (child_process).
- Skill content
const result = spawnSync(command, args, {
Security checks across static analysis, malware telemetry, and agentic risk
TeamClaw’s virtual-team features are mostly consistent with its description, but it can automatically launch worker agents, install additional skills, and pass environment access to workers, so it should be reviewed carefully before use.
Install only if you are comfortable running a multi-agent orchestration service that can start workers, coordinate over the network, use Git, and potentially install additional skills on workers. Begin with local-only mode, disable on-demand provisioning and Git publishing until needed, use isolated workspaces, and carefully limit any environment variables or credentials available to worker agents.
const result = spawnSync(command, args, {const child = spawn(process.execPath, [
const child = spawn(process.execPath, [
const child = spawn(command, args, {const child = spawn(command, args, {...process.env,
...process.env,
const requestedWorkerId = process.env.TEAMCLAW_WORKER_ID?.trim() || undefined;
VirusTotal engine telemetry is currently stale for this artifact.
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.
A controller task could change what a worker has installed and therefore what code or instructions that worker can run.
Worker task preparation can automatically install recommended skills from an assignment before execution. The visible artifacts do not show a local approval gate, source allowlist, or version pinning for those task-driven installs.
import { installRecommendedSkills } from "./src/worker/skill-installer.js"; ... if (assignment.recommendedSkills?.length) { ... const skillInstall = await installRecommendedSkills(assignment, logger);Require explicit user/admin approval for each worker skill installation, restrict installs to an allowlisted registry and pinned versions, and clearly document this behavior in SKILL.md/README.
Worker agents may receive the same credentials or environment-based permissions as the controller process, increasing the blast radius of a bad worker task or compromised worker.
The provided static scan shows local worker processes being spawned with environment access. In this architecture, workers can execute tasks and communicate with the controller, so inherited environment variables may include model/API credentials or other sensitive authority.
Static scan snippets: `const child = spawn(process.execPath, [` and `...process.env,`
Avoid passing the full environment to workers; use an explicit allowlist, redact secrets from logs/events, and document exactly which credentials each worker mode receives.
Enabling provisioning can start additional agent workers on the local host, in Docker, or in Kubernetes.
Launching worker processes, containers, or pods is clearly disclosed and central to the virtual-team purpose, but it means the plugin can create additional execution contexts when configured.
- on-demand worker provisioning with `process`, `docker`, and `kubernetes`
Start with the recommended single-machine/local setup, keep provisioning disabled unless needed, set strict max-per-role limits, and use isolated containers/namespaces for workers.
Other machines on the network may be able to discover or reach the TeamClaw controller depending on host/network configuration.
The controller advertises itself over mDNS and listens for HTTP/Web UI access, including LAN access. This is expected for distributed workers but creates a network boundary users must manage.
await mdnsAdvertiser.start(config.port, config.teamName); ... server.listen(config.port, () => { ... logger.info(`Controller: Web UI available on LAN at ${lanUiUrl}`);Run only on trusted networks, bind to localhost when distributed workers are not needed, and ensure any controller API/UI access is protected by network controls or authentication.
Instructions or task content stored in TeamClaw state may affect later prompts and worker decisions.
The plugin loads team state and injects controller/worker context into prompts. That is purpose-aligned for coordination, but persisted team messages/tasks can influence later agent behavior.
api.on("before_prompt_build", async (_event: unknown, ctx: { sessionKey?: string | null }) => { ... const state = getControllerTeamState() ?? await loadTeamState(config.teamName); const injector = createControllerPromptInjector({Treat team messages and task descriptions as untrusted input, avoid storing secrets in tasks/messages, and provide controls to clear or review persisted team state.
A mistaken or compromised worker task could spread code changes through the shared TeamClaw repository workflow.
Worker task results can be published back through the Git collaboration path. This is expected for software-team collaboration, but bad agent output could propagate into shared repositories or worker workspaces.
publishTaskAssignment: async (assignment) => { ... const publishResult = await publishWorkerRepo(config, logger, controllerUrl, assignment.repo, {Use a dedicated repository or branch, review generated commits before merging to production code, and disable Git collaboration when it is not needed.