Railway Deploy
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: railway-deploy Version: 1.0.0 The skill is classified as suspicious due to the broad `allowed-tools: Bash(railway:*)` permission granted in `SKILL.md`. While the instructions themselves are benign and focused on legitimate deployment actions, this permission, combined with the instruction to use user-provided input for commit messages (e.g., `railway up -m "<MSG>"`), creates a significant risk of shell injection if the AI agent's implementation does not properly sanitize user input before executing `railway` CLI commands. This represents a critical vulnerability rather than clear evidence of intentional malicious behavior within the skill definition itself.
Findings (0)
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.
The agent can start deployments and potentially affect Railway resources through the user's Railway CLI context.
The skill is allowed to run Railway CLI commands. That is expected for deployment, but the wildcard allows more Railway commands than just `railway up`.
allowed-tools: Bash(railway:*) ... Deploy code from the current directory to Railway using `railway up`.
Before use, confirm the target project, service, and environment; prefer giving explicit `--service`, `--project`, or `--environment` details for important deployments.
If the Railway CLI is logged into the wrong account or targets the wrong project, the agent could deploy to an unintended Railway environment.
Deploying to a Railway project/environment uses the user's Railway account permissions. This is purpose-aligned, but it is privileged account activity.
railway up --project <project-id> --environment production --detach -m "Deploy description here"
Check `railway status` or otherwise verify the logged-in account, linked project, service, and environment before allowing deployment.
A mistaken current directory or linked service could send code to the wrong Railway project or environment.
The deployment target can be inferred from the current directory's linked Railway project, which is normal Railway behavior but can cause unintended live-service impact if the working directory is wrong.
Railway CLI walks UP the directory tree to find a linked project. If you're in a subdirectory of a linked project, you don't need to relink.
Use explicit target flags for production or sensitive services, and verify the current directory before running the skill.
If these reference commands were used outside an explicit user request, they could delete or change Railway resources.
A bundled reference documents destructive Railway configuration edits. The main deploy instructions do not make these the default workflow and direct config work to another skill, but the reference is still worth noticing.
### Delete Service ... `isDeleted`: true ... Via CLI: `echo '{"services":{"<serviceId>":{"isDeleted":true}}}' | railway environment edit --json`Treat environment-edit and delete examples as manual, high-impact operations; require explicit user intent before making configuration or deletion changes.
