The silo command
Open Silo from the terminal. silo <path> brings the running app to the foreground (launching it first if it isn't running) and then opens what you pointed it at — mirroring VS Code's code command.
What it does
silo . # open/activate a workspace for the current directory
silo ~/code/my-project # open/activate a workspace for that directory
silo ./README.md # open a file in the active workspace
silo # just bring Silo to the foreground- A directory — if a workspace already exists for that folder, Silo activates it; otherwise it creates a new workspace rooted there and activates it. Relative paths (
.,./sub) resolve against your shell's working directory. - A file — Silo opens the file in the active workspace. If no workspace is active, it first creates one rooted at the file's parent folder.
- No argument — Silo is simply brought to the foreground (or launched).
A second silo invocation never opens a new window: it's forwarded to the already-running instance, which focuses and handles the path. Silo Dev and a release install are independent instances, each with its own command target.
Installing the command
The binary ships inside the app bundle but isn't on your PATH by default. The easiest way to add it:
From inside Silo — run File → Install silo Command in PATH. This writes a small shim to ~/.local/bin/silo pointing at the app binary. If ~/.local/bin isn't already on your PATH, the notification tells you to add it:
export PATH="$HOME/.local/bin:$PATH" # add to ~/.zshrc or ~/.bashrcManually — point a shim or symlink at the app binary directly:
ln -sf "/Applications/Silo.app/Contents/MacOS/silo" /usr/local/bin/siloFor a dev build, the binary lives under the Silo Dev app (Silo Dev.app/Contents/MacOS/silo); symlink that instead to drive the dev instance. Because the command works by launching the real binary (which is then forwarded to the running instance), pointing open -a Silo at the app won't pass the path — use the binary path or the installed shim.