Appium Inspector's attach-to-session list is empty though a locksmith call-out session is running — why?
answer
- the server decides what you see
- an insecure feature, off by default
- the flag needs a scope
- wildcard scope, not a driver name
- restart the server after changing it
basics
~10 sThe Inspector builds that list from GET /appium/sessions, which Appium gates behind the session_discovery insecure feature. Start the server with allow-insecure set to the scoped name *:session_discovery, or the list stays empty.
solid answer
~40 sAttach-to-session is one HTTP call: the Inspector asks the server which sessions it holds, over `GET /appium/sessions`. That route is an *insecure feature* named `session_discovery` and it is off by default, so the server declines and the Inspector shows an empty list even while the session is very much alive. You enable it at server startup with `--allow-insecure`, and in Appium 3 the feature name must carry a scope prefix — the server throws on a bare name. Discovery is the server's own route rather than any driver's, so the scope is the wildcard: `--allow-insecure='*:session_discovery'`. `--relaxed-security` turns the whole insecure set on and will also do it. Either way it is a startup flag, so a server already running will not pick it up.
code
bash · 3 linesappium --allow-insecure='*:session_discovery'
curl -s http://127.0.0.1:4723/appium/sessionsgo deeper
Remember that the attach list comes from the server, not from the device, and that Appium hides it by default. Know the flag name allow-insecure and the feature name session_discovery.
Explain the mechanics: one route, one insecure feature, and a scope prefix Appium 3 requires. Be able to say why discovery takes the wildcard scope rather than a driver's name.
Diagnose it as a checklist — right server, restarted, right base path, session still alive — and argue about where discovery may be enabled and where it must stay off.
Own the posture. Decide whether a shared or hosted Appium server may expose session enumeration at all, and say what the team does instead when the answer is no.
## The list is one HTTP call When you choose attach-to-session, Appium Inspector is not scanning the device or reading a file. It asks the server a single question: *which sessions are you currently holding?* In Appium 3 that request is `GET /appium/sessions` — the migration guide maps the older, unprefixed `GET /sessions` onto it. Whatever the server answers is what the Inspector lists. An empty list therefore means one of exactly two things: the server has no sessions, or the server declined to tell you. ## Discovery is an insecure feature, and it is off by default Appium classifies a handful of server powers as *insecure features*: things a server should not do for any client that can reach its port, but which are perfectly reasonable on a laptop you control. Session discovery is one of them, under the feature name `session_discovery`. With it off, the route is refused, and the Inspector's list comes back empty while your locksmith call-out session runs happily behind it. The reasoning is not academic. Enumerating sessions hands a caller session ids, and a session id is effectively the only credential the WebDriver protocol carries: whoever holds one can drive the device behind it. ## Appium 3 made the feature name scoped The flag that turns an insecure feature on is `--allow-insecure`, and Appium 3 changed how the name is written. A feature name now carries a scope prefix, and the server throws at startup on a bare one. | What you pass | What it means | |---|---| | `--allow-insecure='*:session_discovery'` | The feature is enabled for every driver on this server | | `--allow-insecure='uiautomator2:adb_shell'` | One feature, enabled only for the named Android driver | | `--allow-insecure=session_discovery` | Rejected — the name carries no scope | | `--relaxed-security` | The blunt instrument: the whole insecure set, on | Session discovery is the server's own route rather than any one driver's, so the scope that fits it is the wildcard `*:`. That is the single character-pair most people are missing: - The `*:` prefix is required punctuation here, not an optional flourish - A shell may try to expand a bare `*`, so quote the value - `--relaxed-security` will also enable it, and will also switch on everything else ## When the list is still empty Work down the list rather than re-reading the flag: 1. Confirm the flag went to the server that actually holds the session. A second server on another port is the most common answer, and its session list is honestly empty. 2. Restart the server. `--allow-insecure` is a startup flag; a process already running does not pick up a new value. 3. Check that the Inspector is pointed at the same host, port and base path your test used. 4. Confirm the session still exists. An idle session can be deleted while you are setting the Inspector up, and a deleted session is not hidden — it is gone. 5. Read the server's startup log. A rejected or unparsed flag announces itself there, before any of this becomes mysterious. ## What session_discovery is not - It is not `--allow-cors`. That flag governs whether a browser origin may call the server at all; its failure looks like blocked requests in a browser console, not a tidy empty list. - It is not authentication. Once discovery is on, anything that can reach the port can enumerate sessions, which is precisely why the default is off. - It is not per-session or per-run. It is a posture the server takes at startup, for its whole lifetime. - It is not needed when the Inspector creates its own session. Session creation is an ordinary request; only *joining* a session you did not create needs discovery. ## Where to leave it on, and where not A developer laptop bound to a loopback address is the right home for `*:session_discovery`. A shared or network-reachable server is not. There, prefer letting the Inspector create its own session, or bind the server narrowly with `--address` so that the only clients able to enumerate are ones already on the machine. Treat switching discovery on in a pipeline as a decision to be argued for rather than a default to be copied out of somebody's runbook — the convenience you gain is one click, and the thing you give away is the list of ids that drive every device that server is holding.
- Why is session discovery off by default rather than on?Because a session id is effectively the only credential the WebDriver protocol carries. Anything that can enumerate sessions can drive the devices behind them, so listing them for every caller that reaches the port is a real exposure on any server that is not a private laptop.
- You enabled the flag and the list is still empty — what do you check first?Whether the flag reached the server that actually holds the session, and whether that server was restarted afterwards. A second server on another port, or a process started before the change, explains most of these. Then confirm the host, port and base path match what the test used.
saying these in an interview costs you the question
- Blames the Inspector's build rather than the server's flags
- Writes allow-insecure with the bare name and no scope prefix
- Thinks allow-cors is what gates the session list
- Expects a running server to pick up a new startup flag
- Assumes discovery is safe to enable on any shared server