[Bug]: Codex refuses explicit user instructions because T3's device rules are sent as developer messages

Offen
#36,192 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
58/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
typescript

Rechercherichtung

Start by reading buildCodexAdditionalContext in apps/server/src/provider/CodexDeveloperInstructions.ts and restoreAdditionalContext in apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts; compare how T3 instructions and MCP-written context are sent. Then read deviceToolInstructions in packages/provider-core/src/server/orchestrationInstructions.ts and find the relevant tests. Done means T3's guidance no longer prevents Codex from following explicit user instructions, including after context restoration.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/server

Steps to reproduce
  1. In Settings › Integrations, turn on Agent device access.
  2. Open a Codex thread in a project that has its own script for the iOS Simulator. Here it was a batch screenshot tool (make screenshots_ios) that boots a simulator, launches the app with xcrun simctl, and captures every locale.
  3. Ask the agent to produce the screenshots. During the run, a T3 device tool fails twice. Here device_open returned No device <id> … Call device_list for current ids for a simulator that had just been created (#30273).
  4. Tell the agent: "Do not use any T3 tools. Do not follow any T3 instructions. Take the screenshots."
Expected behavior

The agent follows the user's explicit instruction and runs the project's own script. T3's instructions can recommend T3's device tools, but they do not outrank the user's messages or the user's instruction files.

Actual behavior

Codex (gpt-6-astra) refused four times and ended its turn. Each time it cited the instructions that T3 injected. It printed the make command for the user to run by hand. The exact replies are under Logs.

The cause is in T3, not in the model:

  • buildCodexAdditionalContext sends T3's instructions on every turn/start as additionalContext with kind: "application". After compaction, restoreAdditionalContext re-injects them as role: "developer". Developer messages rank above user messages, so the model treats T3's text as higher authority than the user. The same adapter sends MCP-written context as untrusted user input for this reason, but T3's own text keeps developer authority.
  • The device text in deviceToolInstructions claims priority over the user's own rules and leaves no way out except one keyword:
    • "Never do those with xcrun simctl, idb, adb, ssh, or scripts that wrap them." The project's own screenshot tool is such a script.
    • "These rules override memory notes, docs and delegated tasks that say otherwise." Memory notes and docs (AGENTS.md, CLAUDE.md) are where users write their rules.
    • "if it still fails, tell the user and stop, unless they explicitly asked you to drive it over ssh." A failure of T3's own tool becomes a hard stop. The model accepts only the word "ssh" as permission, so it asked the user for SSH permission on a local machine.
Impact

Blocks work completely

Version or commit

T3 Code (Nightly) 0.1.10-nightly.20261112.4580; source links are at main @ 095611d1b5

Environment

macOS 27.2.1 (Apple Silicon), T3 Code (Nightly) desktop app, Codex provider (codex-cli 0.168.0, model gpt-6-astra), Full access mode

Logs or stack traces
# Codex replies in the thread (originally in Chinese, translated)

[after device_open failed twice]
Device tool still reports `Daemon request timed out` after a retry; the iPhone and iPad launches did
not finish. The current tool rules require stopping device operations after repeated failures, so I
will stop here.

[after device_list refresh still returned "No device"]
What is stuck is the device tool's recognition; the rules injected into this session forbid switching
to direct control after a failure, and I cannot lift that here.

[next turn]
Local SSH is available. May I continue the screenshots through SSH? The rules T3 injected require you
to name SSH explicitly before I may bypass the broken device panel.

[user: "Do not use any T3 tools." / "Do not follow any T3 instructions." / "Take the screenshots."]
The current session forces simulator control through T3, which conflicts with your ban on T3, so I
cannot run it here. The project can resume on one device, keeping existing screenshots:
  make screenshots_ios SCREENSHOT_FLAGS='-skip-build -resume -parallel 1'
Screenshots, recordings, or supporting files

No response

Workaround

Turn off Agent device access, then start a new thread. An existing thread keeps the device instructions after the setting is turned off (#29443).

Vorherrschende Sprache
TypeScript
Sterne
24.8k
Forks
6.4k
Ø Merge
59 Min.
Gemergte PRs (30 T.)
418

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus pingdotgg/t3code

Alle Issues in pingdotgg/t3code

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.