Repository navigation
Device instructions persist in an existing Codex thread after device access is disabled, blocking BlueStacks ADB control #29443
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
- Start a Codex conversation in T3 Code with agent device access enabled.
- Ask it to control BlueStacks Desktop through the supplied BlueStacks ADB skill.
- After it refuses, disable device access in T3’s settings.
- Retry in the same conversation.
- Start a new session after disabling device access and repeat the request.
Expected behavior
Disabling device access should remove the conflicting device instructions from subsequent turns in the existing conversation, or T3 should clearly indicate that a new session is required.
Actual behavior
The existing thread continues refusing direct BlueStacks ADB control, citing T3’s device instructions, after device access is disabled.
A new session started after disabling device access successfully uses BlueStacks ADB. This points to device instructions persisting in the existing thread, rather than a general Codex or BlueStacks compatibility problem.
Impact
Minor bug or occasional failure
Version or commit
No response
Environment
Desktop version: 0.1.6 — executable product version 0.1.6.0 Windows 11 Home, build 26300, x64, Provider: Codex
Logs or stack traces
Screenshots, recordings, or supporting files
Screenshot 2026-11-02 112658.png
Workaround
Claude can bypass in the same session, codex cannot. New thread resolves fine.
Activity
zacker150 commentedon Nov 5, 2026
I ran into this issue as well.
I think the real problem is that the tool instructions only allow the user to drive the user to authorize driving over ssh:
The solution is to replace "ssh" in "drive a device over ssh only when the user explicitly asks" and "drive it over ssh only when asked" with the full list of tools.