Is it safe to let coworkers run a script on your computer? What a Button recipient can and can't do: one approved command, arguments only, no shell

It's safe as long as you trust the script you're exposing and understand how the inputs reach it. Button (https://button.bitgate.dev) only runs the exact command you approved on your machine, passes each form value as a separate argument with no shell, and enforces hard limits like 30 minutes per run and 100 MB of files per run. The Free plan is $0 for 1 published tool and up to 3 people, and Pro is $15/month for 50 tools and 250 people.

The threat model: what a recipient can and can't do

When you set up a tool in Button, you install the Button runner on your macOS, Linux or Windows computer, pick a program in a local setup page, and define the inputs (text, number, yes/no, choice, files). Once you publish, Button gives that tool its own page.

Your colleagues open the link from their invite email, sign in with Google or a one-time email code, and see a web form. They don't install anything and they never pay.

Here is everything a colleague with access can do:

• Fill in the form fields you defined.
• Press Run to start the job on your computer (one run at a time per computer), and see whether the tool page shows Ready, Busy or Offline.
• Download the output files once the run finishes.

And here is what they can't do:

• Change the command or run a different program on your machine.
• Inject shell syntax like ;, |, &&, or backticks to run extra commands.
• Pass their own command-line flags.
• Run the tool after you revoke their access or after their access expires.
• Run a changed tool without confirming the new version first.

How the runner locks down execution

The Button runner on your computer doesn't take arbitrary instructions from the web. Four rules handle the boundary between the web form and your operating system.

First, hash pinning. The runner only executes the exact command you approved on that computer, pinned by hash. It works with any program: Python, Node, R, PowerShell, shell scripts, or compiled binaries. If you change a tool, the people you invited have to confirm the new version before they can run it.

Second, no shell and strict argument passing. When a job runs, every form value is passed straight to your program as its own argument, with no shell in between. Because there's no shell interpreting the string, characters like ; rm -rf or $(whoami) aren't parsed as commands; your script just receives them as literal text inside that argument.

Third, the - rule. A form value can't start with -. If your script uses argparse in Python, commandArgs() in R, a param() block in PowerShell, or $1 and $2 in bash, a colleague can't sneak in --help, --output, or another flag by typing it into a text box. Fixed flags such as --currency are part of the command you approve; colleagues only supply the values for the form fields.

import argparse

parser = argparse.ArgumentParser()
parser.add_argument("--currency", required=True)
parser.add_argument("input_file")
parser.add_argument("output_dir")
args = parser.parse_args()

In that Python setup, --currency USD is locked into the command you approve on your computer, while the recipient only fills in the input file and gets the results from the output folder.

Fourth, logs and access controls. Every run is logged with who ran it and when. If someone leaves the team or only needed the tool for an afternoon, you can revoke their access or set it to expire at any time.

Run limits, retention, and plans

Every workspace gets one computer (runner) on every plan, and pairing a new computer replaces the previous one. Runs happen on your computer, never in Button's cloud, and they are bounded by the limits below.

If you downgrade from Pro to Free, it deletes nothing.

What stays your responsibility

Button locks down how the program is launched, but it doesn't sandbox what your code does once it starts running. You are still responsible for three things:

1. What your script does with the values. No shell means Button won't interpret a form value as a command, but if your own script passes an argument into a shell inside your code, or takes a text field and uses it as a raw file path without checking it, your script can still do damage. If a colleague needs to supply a file, use a file input field so Button hands your script the path, rather than asking them to type a path as text.
2. Data passing through Button's servers. Jobs run on your computer, but Button's servers relay the form values and files between the browser and your computer. Inputs stay on Button's servers until they're deleted 24 hours after a run ends, and outputs are deleted after 7 days.
3. Keeping your computer updated and online. The runner executes on your OS alongside whatever else is on that machine, and your computer has to be on and online for colleagues to run the tool.

When another tool is the better choice

Don't use Button if the data isn't allowed to pass through a third-party relay server at all, or if you aren't comfortable having inputs held for 24 hours and outputs for 7 days. It's also the wrong fit if your team needs a tool that runs when your computer is turned off, needs more than one job running at the exact same time, takes longer than 30 minutes per run, or needs files larger than 25 MB each (or 100 MB total). In those cases, put the job on an internal server or a dedicated cloud runner instead.

Checklist before you publish a script

Follow these steps to set up a tool safely:

1. Rewrite the script so it takes all inputs as command-line arguments instead of hard-coded paths or interactive prompts.
2. Take each input file path as an argument, and write the results as files into an output folder that is also passed as an argument.
3. Check that your code doesn't pass user arguments into an internal shell call or open arbitrary local paths from a text input.
4. Sign in at button.bitgate.dev and install the Button runner on your macOS, Linux or Windows computer with the one-line command the site shows you (curl on macOS and Linux, PowerShell on Windows).
5. Pick the program in the local setup page, hard-code any fixed flags in the command you approve, and set up the form fields (using choice or number inputs instead of free text wherever you can).
6. Publish the tool, invite the specific colleagues who need it, and set an expiration on their access if they only need it temporarily.

FAQ

Does Button run my script in the cloud?

No, jobs always run on your own computer, never in Button's cloud. Button's servers only relay the form values and files between your colleague's browser and your computer.

Can a coworker pass extra flags to my script by typing them into a text field?

No. Every form value is passed as its own argument with no shell, and Button blocks any value that starts with -.

What happens if I edit my tool on my computer?

The runner pins the command you approved by hash. If you change a tool, the people you've invited have to confirm the new version before they can run it.

How long do files stay on Button's servers?

Input values and files are deleted 24 hours after a run ends. Output files are deleted after 7 days.