An APX Android app that works at your desk can stop connecting when you unplug the cable. The installation may be fine. The daemon address saved during pairing can explain the failure.
The practical rule: choose and test the connection for the place where you intend to use the phone. A successful USB setup does not prove that the same address works over Wi-Fi or mobile data.
APC is the portable context layer: project instructions and definitions live in AGENTS.md and .apc/. APX is the daily-use runtime and tooling layer: its daemon manages execution and exposes surfaces such as the Android app. Moving to a phone changes how you reach that runtime; it does not move the project or daemon onto the phone.
Three addresses, three reachability limits
The APX Android installation guide documents three connection paths:
| Connection | What the phone reaches | When it stops working |
|---|---|---|
| USB tunnel | Daemon through adb reverse
|
Cable disconnected |
| LAN address | Daemon on the local network | Phone leaves that network |
| Tailscale HTTPS address | Daemon through the same tailnet | Required devices or network path unavailable |
With USB forwarding, http://127.0.0.1:7430 on the phone can reach the computer's daemon. The forwarding makes that possible. Without it, the phone's loopback address is not an address for your computer.
For LAN access, the documented setup is:
apx panel share
apx restart
Use the actual address reported for your machine. An example such as http://192.168.x.x:7430 describes an address shape, not a value to paste literally. This connection suits a phone and computer on the same reachable local network.
For access beyond that network, APX documents:
apx panel tailscale on
This uses Tailscale Serve and an HTTPS address inside the tailnet. It does not publish the daemon through Tailscale Funnel. Both devices need the appropriate tailnet connectivity, and the computer still needs to remain available.
Check the selected address after installation
The current guide says apx android install checks addresses the daemon serves against addresses the phone can reach. It prefers a working tailnet path and uses the USB tunnel as a fallback. That is useful automation, but the fallback matters: a successful installation may still leave you depending on the cable.
Start by inspecting the installation:
apx android status
This reports the attached phone, installed version, adb, and tunnel. Then check which daemon URL the app actually retained. For manual pairing, apx pair web provides a code and QR; enter the intended daemon URL in the app along with the code.
Test the intended path directly. For LAN use, disconnect USB and open the app again while staying on Wi-Fi. For away-from-home use, test with the phone off that Wi-Fi and connected to the tailnet. Read a fresh piece of daemon data so a previously rendered screen does not stand in for connectivity.
Keep the diagnosis narrow
If the app fails only after unplugging, inspect the stored URL and tunnel dependency before reinstalling. If it fails only outside the house, inspect whether it was paired to a LAN address.
Those symptoms point to reachability. They do not establish that the APK is damaged or that the project's APC context needs changing. Keeping that distinction clear gives you a small, repeatable check before touching an otherwise working setup.
The commands and Android client belong to the APX repository.
Top comments (0)