> ## Documentation Index > Fetch the complete documentation index at: https://visorai.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Command reference > See every Visor command, the inputs it accepts, and the shape of the data it returns. This page documents the current command surface exactly as implemented. If you run `visor --help`, `visor -h`, or invoke the CLI with no command, Visor prints a usage summary instead of a JSON response envelope. `visor --version` and `visor -v` print the package version instead of a JSON response envelope. ## Global runtime inputs These inputs are accepted globally and, where relevant, by individual commands. | Input | Meaning | | - | - | | `device` | Device or simulator identifier | | `timeout` | Per-step timeout budget in milliseconds for scenario runs | | `output` | Base output directory for run artifacts and reports | | `format` | `text` or `json` | | `server-url` | Appium server URL | | `app-id` | Android app package or iOS bundle identifier; on iOS it must match an installed app on the selected target | | `map-dir` | Explicit directory for the runtime index, compact agent memory, and route checkpoints | | `attach` | Attach to an already running app process when possible | | `no-map` | Disable app-map reads and writes for this command | | `repair` | Allow opt-in exploratory app-map repair after a missing or stale route | Important notes: * `format` is currently informational only for normal commands; the implementation still returns JSON envelopes * `visor --help`, `visor -h`, and no-command invocation print plain-text usage instead of JSON * `visor --version` and `visor -v` print the package version instead of JSON * `platform` is inferred from the selected device; `--platform` is not accepted ## Mapped execution Visor enables mapped execution by default for direct action commands and scenario runs. It observes lightweight UI source around target actions, stores a schema-versioned host-machine app map under `.visor/maps`, and can reuse confirmed navigation edges when a later command targets a known screen from a different current screen. Agents should follow the repository-installed `visor-discovery` skill: read compact agent memory before visual evidence, use `route` for multi-step navigation, and use `discover` only to name or repair unknown live states. See [Agent memory and deterministic routes](/docs/features/app-map). Use `--no-map` or `VISOR_NO_MAP=true` when you need raw Appium behavior. No-map mode disables both map reads and map writes. Exploratory repair is off by default. Use `--repair` when you want Visor to try safe controls after a missing or stale route instead of failing fast. Every mapped direct action returns `data.map`. Mapped target, coordinate, and scroll actions also return `data.observation` with before/after fingerprints, `screen_changed`, previous/current screen ids, and `visible_text_count`. Scenario runs return `data.run.map` and per-step map details under `data.run.steps[].details.map` when a step used routing, repair, or map observation. ## Direct action commands ### `tap` Purpose: click an element or coordinate. Inputs: * target mode: `target` * coordinate mode: `x`, `y` * optional: `normalized` * optional post-action wait: `--wait-for`, `--timeout`, and `--poll-ms` to wait for a selector after the tap Returns action payload fields: * `action` * `platform` * `args` `args` contains either: * `target`, or * `x`, `y`, and `normalized` Coordinate `x` and `y` values are screen points by default. With `normalized`, they are fractions of the current screen width and height. Coordinate taps work as direct commands and as scenario steps. Target taps report `args.tap_method`; when Visor can resolve an element rectangle, it taps the center coordinate and returns the resolved `x` and `y`. Examples: ```bash theme={null} visor tap --target accessibility=Continue visor tap --target text=Continue visor tap --target text~=Settings visor tap --target "first-in-section=Featured products" visor tap --x 120 --y 640 visor tap --x 0.5 --y 0.92 --normalized ``` ### `navigate` Purpose: move to a destination. Required input: * `to` Returns action payload fields: * `action` * `platform` * `args.to` Current behavior: * the destination is passed to WebdriverIO through `url(to)` ### `act` Purpose: perform a helper action. Supported variants: * `name=type` with `target` and `value` * `name=type` with `value` only, which types into the active field * `name=back` * `name=home` * `name=reset` * `name=drag` with `start-x`, `start-y`, `end-x`, and `end-y` * `name=slider` with `target`, `value` from `0` to `1`, and optional `start-value` `drag` also accepts `normalized` so coordinates can be fractions of the viewport. `reset` requires `app-id` because Visor restarts the target app. Optional post-action wait inputs: * `--wait-for` * `--timeout` * `--poll-ms` `--wait-for` polls for a selector after the helper action completes. `--timeout` and `--poll-ms` control that post-action wait. Returns action payload fields: * `action` * `platform` * `args` ### `scroll` Purpose: perform a page-style vertical scroll. Required input: * `direction` with value `up` or `down` Optional input: * `percent`, default `70` * post-action wait: `--wait-for`, `--timeout`, and `--poll-ms` `--wait-for` polls for a selector after the scroll completes. `--timeout` and `--poll-ms` control that post-action wait. Returns action payload fields: * `action` * `platform` * `args.direction` * `args.percent` Current behavior: * Android uses Appium scroll gestures within the current viewport * iOS attempts the same gesture path and falls back to a touch swipe when needed ### `screenshot` Purpose: capture a PNG image. Optional input: * `label` * `path` * `settle` or `settle-ms` Returns action payload fields: * `action` * `platform` * `args.label` * `args.file` * `args.path` * `args.width` * `args.height` If `label` is omitted, the runtime defaults it to `capture`. If `path` is provided, Visor writes the PNG to that path. Otherwise it writes `