Android Remote image attachments are not routed as active-turn steering

Summary

Android Remote previously supported steering an active Codex turn with a message containing an image. That feature used to work: the active turn received the image as part of the user’s steering/addendum input.

It no longer works reliably. When I send an image-bearing steering message from Android Remote, the active turn does not receive the image. Depending on timing:

• the accompanying text may reach the active turn while the image is absent; or
• the image may appear only after the active turn ends, as a separate ordinary message.

This is a regression in image-bearing steering, not a request for a new feature.

Verified environments

Observation	Android app	Windows Codex Desktop	Host	Connection
Original reproduction, 2026-08-09	1.2026.209 (Google Play)	Exact package version was not captured	Windows 10 x64	4G cellular
Instrumented reproduction, 2026-08-29	1.2026.230 (versionCode=2623032)	26.825.5331.0	Windows 10 Home 22H2 x64, build 19045.7663	Android Remote; ADB diagnostics over local Wi-Fi

The exact Desktop package installed during the original August 9 reproduction was not recorded, so I am not assigning that occurrence to a guessed version. The later instrumented reproduction is directly verified on Desktop 26.825.5331.0.

Steps to reproduce

1. Start a Codex task on the Windows host and leave an assistant turn actively running.
2. Open that same task through Remote on Android.
3. Attach a photo/image to the composer.
4. Add optional text.
5. Send the image-bearing message while the assistant turn is still active.
6. Observe that the active turn does not receive the image as steering input.

Original reproduction

On August 9, an image sent from Android while the assistant was working did not reach that active turn. The image surfaced only later, after the turn had ended or paused, as a separate ordinary user message.

The supporting screenshots also could not be delivered from mobile at the time of the failure. They were uploaded later from Windows. Their eventual presence in the conversation is not evidence that image steering succeeded.

Instrumented text-versus-image reproduction

A later A/B capture on August 29 isolated the image-specific failure:

• Android visibly showed a photo attached in the active steering/Goal composer with accompanying text.
• The Windows rollout received the complete text.
• The Windows rollout contained no image, attachment, file, input_image, or local_image item.
• Text-only steering continued to reach the same active turn.

This proves that the active Remote connection and text steering path were working while the image portion of the same submission was not delivered.

Sanitized Android log excerpt

21:34:04.580  ActivityTaskManager  create Photo Picker activity for ChatGPT task
21:34:04.653  ActivityTaskManager  start android.provider.action.PICK_IMAGES type=image/* from <CHATGPT_UID>
21:34:04.800  Photopicker          callingPackage=com.openai.chatgpt mimeTypes=[image/*] selectionLimit=4

The release Android build does not log the selected image URI or outbound request body. Android-side proof is therefore:

1. the pre-submit screenshot visibly showing the attached photo and text; and
2. the system log showing ChatGPT launching an image-only picker.

Sanitized Windows rollout excerpt

21:35:19.314  event_msg      thread_goal_updated
                         objective=<TEXT_PRESENT>
                         image/attachment fields=<ABSENT>

21:35:20.746  response_item  role=user
                         content=[{type=input_text, source=goal}]
                         content_item_kinds=[goal.internal_context]
                         input_image/local_image items=<ABSENT>

The private message text, task/message IDs, local paths, and image contents are omitted. The event types, timestamps, and delivered content shape are preserved.

False-positive “working” result

One apparent success was not actually successful steering. The assistant turn ended at approximately the same moment the photo was sent, so the image appeared afterward as a normal next message.

That timing can make the regression look intermittent: the image appears in the conversation, but it did not modify the active turn as intended.

Expected behavior

A steering message containing text and an image should reach the active turn atomically:

active turn + Android steer(text, image)
    -> active turn receives text and image

If image steering cannot be delivered, Android should explicitly refuse it instead of silently dropping the image or converting it into a later standalone message.

Actual behavior

active turn + Android steer(text, image)
    -> active turn may receive text only
    -> image is absent, or appears later outside the intended turn

Workaround

The only reliable workaround observed is:

1. send a text-only request asking the assistant to pause;
2. wait until the turn has actually stopped;
3. send the image as a normal message.

This does not restore image steering; it only avoids losing the image during an active turn.

Why this matters

Images are often the fastest way to correct an agent performing UI work. When the text arrives but the screenshot does not, the agent can continue acting on stale visual information while the user believes the correction was delivered.

Evidence retained

• Original August 9 screenshots and environment details
• Android pre-submit screenshot showing the attached photo and steering text
• Android ADB/logcat window covering image selection
• Windows rollout records showing text-only delivery
• Controlled text-only steering results from Android and Desktop

Raw artifacts are retained locally and are not attached verbatim because they contain private message text, task IDs, local paths, host identifiers, image contents, and unrelated Android activity. The sanitized excerpts above preserve the relevant image-selection and text-without-image delivery evidence.

Start at the Android Remote composer’s active-turn steering/addendum entry point and trace how text and image payloads are routed. Compare the text-only and image-bearing paths, then verify that an active turn receives both atomically, or that Android explicitly refuses image steering instead of dropping or deferring the image.