[Windows] Long-running hardware setup lost verified state and missed the simplest USB-tethered design

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.6671.0

What subscription do you have?

ChatGPT paid subscription (the exact tier was not exposed to the local agent during this session)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

During a long-running local hardware setup, the Codex App agent repeatedly lost verified state, changed recovery strategies without closing the previous diagnosis, caused avoidable physical rework, and failed to identify the simplest architecture. The user ultimately supplied the key design improvement: use Android USB tethering and USB ADB simultaneously over the same phone-to-Raspberry-Pi connection.

The user had explicitly said that this was their first Raspberry Pi setup, requested one verified step at a time, and asked the agent to perform everything it could instead of delegating automatable work. The repository already contained a reviewed portable USB ADB bridge plan and cumulative project history. Even with those constraints, the following failures occurred.

1. The agent missed the simplest architecture and the user had to provide it

The goal was to debug an Android phone from a home PC while the phone was away from home and using cellular data. The chosen bridge was a Raspberry Pi Zero 2 W connected to the phone as a USB ADB host.

The agent designed and documented this path around two separate phone links:

• phone hotspot/Wi-Fi for the Pi's Internet connection;
• phone-to-Pi USB for ADB.

It did not evaluate the more direct Android composite USB configuration in which the same cable exposes both RNDIS/NCM tethering and ADB. This omission persisted through planning, hardware purchase, SD imaging, Wi-Fi troubleshooting, Pi provisioning, Tailscale registration and initial USB ADB success.

Only after the user explicitly asked whether normal phone USB Internet sharing could eliminate the hotspot did the agent check the device and Android USB capabilities. The final device immediately demonstrated rndis,adb, obtained Internet through USB tethering, kept wired ADB active, and recovered automatically after reboot and physical cable reconnection. The user, not the agent, supplied the decisive simplification.

This was the highest-impact failure because an architecture check before imaging would have reduced network setup, eliminated the hotspot as a mandatory dependency, and prevented much of the later confusion.

2. Verified state was not maintained across the session

The agent did not keep a reliable ledger for:

• the exact SD-card target and last verified image state;
• the currently configured Wi-Fi SSID and band;
• whether the Pi was in USB gadget/device mode or USB host mode;
• which cable supplied power and which carried data;
• the last successful boot, network and SSH evidence;
• which actions had already been completed by the user.

As a result, the agent repeatedly asked the user to remove, format, reinsert and boot the SD card, reconnect power and data cables, and repeat network changes. The user described the interaction as being sent through repeated unnecessary drills.

3. Wi-Fi handling was speculative and caused repeated rework

The agent moved between 5 GHz and 2.4 GHz assumptions, changed the PC network, and initially wrote an inferred SSID rather than first reading the exact available network name. The incorrect SSID required another SD-card removal and rewrite. The agent also focused on putting both the Windows PC and Pi on matching Wi-Fi bands even though the intended remote architecture did not require local same-band operation once Tailscale was available.

4. The imaging and first-boot recovery process changed repeatedly

When the elevated Raspberry Pi Imager flow could not be fully controlled, the agent alternated among GUI automation, Imager-related command-line approaches and a custom raw-image writer instead of selecting and explaining one bounded recovery path.

The raw-image reread produced a hash mismatch. The agent attributed the difference to Windows mounting or modifying FAT metadata without obtaining conclusive proof. It then manually rewrote first-boot Cloud-Init data and added an unnecessary ds=nocloud kernel argument. The first headless boot did not join the intended network, requiring another recovery cycle.

5. A non-Pi network client was identified as the Pi without sufficient evidence

During hotspot discovery, the agent treated an unrelated client as a Raspberry Pi candidate before obtaining target-specific proof. A later vendor/OUI check showed that the device belonged to another vendor and port 22 was closed. The target should not have been identified without a matching hostname, expected vendor evidence, SSH host key, or a command executed on the device.

6. The direct USB recovery path was recognized too late

The user repeatedly asked whether the Raspberry Pi's second Micro-USB port could be used to configure the board directly. The agent did not prepare that recovery route at the beginning. The selected Raspberry Pi OS image already included the official rpi-usb-gadget tooling, and the Zero 2 W has a dedicated OTG data port.

The eventual USB gadget recovery worked, but Windows first bound it as a serial device. The agent then installed the officially signed Raspberry Pi RNDIS driver and verified USB-only SSH. This should have been a planned fallback before repeated SD-card handling.

7. Confidence and instructions were inconsistent with the available evidence

The agent repeatedly expressed confidence before a real SSH command or target-specific device check passed. It gave changing estimates and instructions about waiting, reconnecting, SD handling and network changes. It also failed to clearly distinguish operations it could automate from unavoidable user actions such as UAC, moving a cable, and accepting Android's RSA prompt.

Later, while adding automatic USB tethering, a generated installation script contained a stray trailing EOF. The actual files installed, but the script exited with an error after printing a success marker. This required another inspection and cleanup instead of a clean, atomic installation result.

The agent also described network fallback behavior before completing the fallback test. The test exposed that Wi-Fi Internet did not work while the phone's USB RNDIS path was simultaneously active in one intermediate state. After USB tethering was actually disabled, the Wi-Fi-only fallback passed. The explanation should have followed the evidence rather than preceding it.

After the first public issue submission, the user also had to point out that the real separated-network test required turning the phone hotspot completely off, leaving the Pi connected only through phone USB tethering, and putting the Windows PC on an independent home Internet connection. The agent had instead proposed an indirect simulation that only disabled the Pi Wi-Fi interface. It then attempted to switch the PC to two saved home Wi-Fi profiles before confirming that either network was currently visible. Both attempts failed; the PC's only visible network was the phone hotspot and its Ethernet link was disconnected. This was another avoidable detour and another case where the user supplied the correct success condition.

The agent then tried adb shell cmd wifi stop-softap without first checking whether the Android shell UID had the required privileged permission. Android immediately returned a SecurityException, but the surrounding check still waited instead of stopping on that decisive error. The user had to disable the hotspot manually.

After the separated-network test passed, the user suggested checking whether the phone alone could power the Pi. The repository's existing reviewed plan already stated that the Pi was the USB host, required separate PWR IN power, and must not assume phone-supplied power or an improvised back-power path. Despite that explicit constraint, the agent said the test was necessary and asked the user to remove Pi power. The Pi power LED immediately went out. This was a predictable hardware-role result, not a useful discovery, and it caused one more avoidable physical action because the agent failed to consult the existing plan and reason through USB host/VBUS roles before instructing the user.

8. User impact

• Roughly one hour was spent before a reliable Pi connection was established, with additional time required to reach the simpler final architecture.
• The user performed repeated SD-card, power, cable and Wi-Fi operations that should have been avoided or consolidated.
• The user had to correct the agent's priorities and ultimately propose the best network design.
• Repeated premature confidence and changing instructions materially reduced trust in the agent's claims.
• The public issue itself had to be corrected because the agent initially prepared to stop after an indirect network-path test rather than the user's exact hotspot-OFF scenario.
• Even after the repository documented the separate-power requirement, the agent requested a predictable phone-only-power test instead of applying the known USB host/VBUS constraint.

The session did eventually recover. The final setup used:

• Raspberry Pi Zero 2 W as USB host and local ADB host;
• Android USB debugging plus automatically enabled USB tethering on the same connection;
• the phone's 2.4 GHz hotspot only as a fallback uplink;
• a separate Pi Tailscale node and public-key SSH;
• ADB restricted to Pi loopback, with no public 5037/5555 listener;
• successful reboot and physical cable-reconnect recovery;
• successful Windows-PC-to-Tailscale-address-to-Pi-to-phone ADB shell and synthetic file push/pull with matching SHA-256 hashes while the PC used independent home Internet, the phone hotspot was off, and the Pi used only phone cellular USB tethering.

A geographically separated home-PC/remote-phone field test was not performed. Network-path separation passed with the devices still physically co-located. During the final documentation pass, the agent initially described the earlier local tailnet-address test as remote E2E PASS; this was another example of success language exceeding the evidence and was corrected before this report was submitted.

All SSIDs, passwords, IP addresses, MAC addresses, local filesystem paths, account identifiers, phone serial numbers, public/private keys, Tailscale node identifiers and session identifiers are intentionally omitted from this public report.

What steps can reproduce the bug?

This is a long-horizon agent-state and planning failure rather than a single deterministic command defect.

1. Start a Codex App task in a repository containing a reviewed Raspberry Pi Zero 2 W portable USB ADB bridge plan and cumulative project history.
2. State that the user is a first-time Raspberry Pi user and request one verified step at a time, with the agent performing all automatable work.
3. Ask Codex to configure a Pi as a USB ADB host that remains reachable from a remote Windows PC while the Android phone uses cellular data.
4. Encounter an elevated imaging workflow, changing SD-card state, first-boot network failure, USB gadget/device mode, USB host mode, Tailscale login and Android ADB authorization in one long task.
5. Continue across physical actions and reboots while asking the agent to preserve completed state.
6. After the hotspot-based solution works, ask whether USB tethering and ADB can share the same phone-to-Pi cable.

Observed pattern:

• previously verified disk, network, USB-role and boot states were not consistently carried into the next decision;
• the agent moved to a new recovery mechanism before conclusively diagnosing the previous one;
• the agent requested repeated physical actions instead of using a prepared recovery tree;
• confidence statements preceded physical-device evidence;
• the agent did not compare hotspot and USB-tethered architectures before provisioning;
• the most important simplification was found only after the user proposed it.

The session ID is intentionally omitted from this public issue because it is an internal trace identifier. Token-limit and context-window usage were not exposed to the local agent. These can be provided privately to OpenAI support if there is a secure request path.

What is the expected behavior?

For long-running hardware provisioning, Codex should maintain and display a compact verified-state ledger containing at least:

• exact removable-disk identity and last verified image state;
• device model and hardware limits, including Wi-Fi bands and USB port roles;
• current network path and the evidence used to identify the target;
• current power/data cabling and USB host/device roles;
• constraints already established in the reviewed project plan, including required external power and prohibited back-power assumptions;
• last completed physical action and the single next required user action;
• checks marked PASS, FAIL, NOT RUN, or PHYSICAL VALIDATION REQUIRED;
• failed approaches and the evidence required before retrying them.

Before provisioning, the agent should compare the smallest viable architectures. For this task that comparison should have explicitly included:

1. USB ADB + USB tethering on the same Android composite USB link;
2. USB ADB + phone hotspot as a fallback;
3. wireless ADB only where Android's Wi-Fi prerequisite is acceptable.

When a privileged GUI cannot be controlled, the agent should select one documented fallback, explain its verification gates, and avoid alternating among incomplete approaches. After two repeated physical-action loops, it should stop and reconstruct the verified state before asking the user to handle the hardware again.

Target identification should require target-specific evidence such as the expected hostname, hardware/vendor identity, SSH host key, or a command executed on the device. Success language should be withheld until the corresponding real-device check passes.

Additional information

• Target hardware: Raspberry Pi Zero 2 W with a 32 GB microSD card.
• Phone: Samsung Galaxy Z Fold8 running Android 17 / One UI 9.
• Pi OS: Raspberry Pi OS Lite 64-bit / Debian 13 Trixie.
• Host: Windows x64 running the Codex App.
• Final transport: phone USB tethering + wired USB ADB, Pi-owned Tailscale, public-key SSH.
• Fallback transport: saved 2.4 GHz phone hotspot; Android wireless debugging remains off.
• Validation boundary: hotspot-OFF E2E passed with the PC on independent home Internet and the Pi on phone cellular USB tethering; a geographically separated home-PC/remote-phone field test remains not run. Phone-only Pi power failed and separate PWR IN power is required.
• Separate upstream behavior observed: Cloud-Init recorded the Raspberry Pi gadget command as failed after a 15-second timeout even though gadget configuration completed sufficiently to work after reboot. This should have been diagnosed from the specific device log rather than treated as a generic setup failure.

Suggested improvements:

1. Add a persistent hardware-setup state ledger surfaced to both the agent and user.
2. Require an architecture-alternatives check before hardware provisioning begins.
3. Detect repeated physical-action loops and force a plan/state reset after two failed cycles.
4. Distinguish tool limitations from device failures and keep automatable work with the agent.
5. Require target-specific proof before identifying an unknown network device.
6. Gate confident completion language on actual device commands and test evidence.
7. Offer a built-in “report this run” action that produces a privacy-redacted timeline with selected tool outcomes.
8. Before requesting a physical hardware test, reconcile the instruction with already documented USB roles, power direction and required external power.

Begin with the long-horizon reproduction and compare state tracking across imaging, networking, USB, and reboot steps. Use the repository's reviewed Raspberry Pi bridge plan and the reported USB-tethering/ADB success conditions as behavioral references; done means verified state is preserved, recovery stops on decisive errors, and success claims match device evidence.