Use the Push CLI and scripts
Run useful Push commands directly, inspect their help, and use structured results in your own workflow.
The push CLI is the command surface used by you and the Push skill. Use the skill for conversational work and direct commands for repeatable lookups or scripts.
Set up the command
Push bundles the CLI. Use Settings → Workspace → Push CLI and skill to install or repair it and follow the displayed PATH instructions if your shell cannot find push.
Run commands in a shell. In an active agent conversation, ask the agent to run the command instead; pasting shell syntax as a message does not change that conversation into a shell.
Start with a useful lookup
push status| Task | Command | Where to go next |
|---|---|---|
| Find what needs attention | push attention | Open the named work and read its current request. |
| Find tracked work | push session list --match "launch" | Use the returned work reference. |
| Track this untracked conversation | push track "Prepare the launch" | Find it on the board; use the current Push tab. |
| Check the installation | push doctor | Follow the specific diagnostic's recovery. |
| Learn a command | push session list --help | Check available flags on your installed version. |
See tracking, status, results and recording reports for complete tasks.
Use structured results
For a read in a script:
push session list --status active --jsonCheck the command's exit status before using the output. Read its error if it fails; do not treat a failed request as an empty successful result. Inspect the returned fields on your installed version before writing a parser. --help describes each command's available flags; --json is not universal across every operation.
Use read commands while developing an integration. Before adding a write, establish the target workspace, person, access and intended effect. Store credentials using your normal secret management; never embed them in a public example or share link.
Limits and recovery
The CLI uses the access available to its connection. It cannot grant itself human permissions, make an offline Mac execute work, or bypass a refusal by changing transports. Internal support and compatibility commands are not an integration contract merely because they appear in help.
A public API or SDK guide must name a supported release and operation. Use the published CLI workflows here for current automation; source code and private API inventories are not public instructions.
If setup fails, see troubleshooting. For a particular operation, read its nested help and follow the refusal's next step.