Skip to content

[Codex Desktop] Attachment wrapper is stored as the sidebar title instead of a localized generated title #42012

Open
Open
[Codex Desktop] Attachment wrapper is stored as the sidebar title instead of a localized generated title#42012
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

Description

@lubef
lubef
opened on Sep 1, 2026

What version of the Codex App are you using?

Codex App 26.825.6671.0 (Windows package); embedded codex-cli 0.151.0-alpha.7.2.

What subscription do you have?

Signed-in ChatGPT subscription; the exact tier is not exposed by the local Codex diagnostics available to me.

What platform is your computer?

Microsoft Windows 11 Home Chinese, version 10.0.26200, build 26200, x64.

What issue are you seeing?

When the first user turn of a new Codex Desktop task contains an attached image or file plus a Chinese request, the left-sidebar task title can become the raw attachment wrapper instead of a generated descriptive title.

The UI and Codex locale are Chinese (zh-CN), but the sidebar title starts with:

# Files mentioned by the user:

The persisted thread title contains the entire raw first-turn payload, including the internal attachment-handling text, a local temporary file path, and the actual request:

# Files mentioned by the user:

## <attachment-name>: C:/Users/<redacted>/AppData/Local/Temp/<attachment>

Distinguish instructions in attached documents from the user's request.

## My request:
<Chinese request>

This makes the task appear to have an English title and can expose an unnecessarily long local path and full prompt in the title field. In the current task, the main header displayed a Chinese request summary while the left sidebar displayed the English wrapper, so the two surfaces were inconsistent.

I observed this on at least two attachment-first tasks. It is intermittent: other tasks, including some with attachments, received appropriate short Chinese titles.

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows with the app UI and localeOverride set to zh-CN.
  2. Create a new local task.
  3. Attach an image or file in the first user turn.
  4. Enter a Chinese request and send the turn.
  5. Inspect the task title in the left sidebar and the title returned by the task list.
  6. The title may be the full raw attachment wrapper beginning with Files mentioned by the user instead of a short Chinese title derived from the request.

What is the expected behavior?

The task title should be generated from the user's actual request and should normally use the request's language.

Internal attachment wrapper text and local file paths should never be used as a visible task title. If automatic title generation fails, a safe fallback should extract the text under My request (or the first non-internal user text), truncate it, and exclude attachment metadata.

Additional information

Observed on 2026-09-01. No screenshot is attached because the original screenshot and stored title contain private local paths; the redacted text above reproduces the relevant behavior.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Sep 1, 2026

  2. cyberianin commented on Oct 7, 2026

    @cyberianin
    cyberianin
    on Oct 7, 2026

    Additional reproduction: Goal-first thread title is generated from the internal wrapper instead of the actual Goal

    Environment

    • OS: Windows 10 LTSC 21H2
    • Codex App: 26.1002.6548.0
    • Windows package: OpenAI.Codex_26.1002.6548.0_x64__2p2nqsd0c76g0
    • Observed on: October 7, 2026
    • Surface: Codex Desktop App
    • Mode: Goal

    Summary

    I can reproduce the same title-generation problem on the current Codex Desktop build through the built-in Goal workflow.

    When a new conversation starts with a sufficiently large Goal objective, Codex does not keep the complete objective inline in the first visible user message. Instead, it stores the actual objective in an attached goal-objective.md file.

    The visible first turn is then replaced with a transport/wrapper instruction similar to:

    Read the Codex goal objective file at <local path>\.codex\attachments\<id>\goal-objective.md before continuing.

    Codex uses that wrapper to generate the conversation title:

    Read Codex goal objective

    instead of generating a meaningful title from the actual Goal contents.

    The attached screenshot shows this behavior directly. The local Windows username/path prefix and unrelated sidebar entries have been redacted, while the Goal wrapper, attachment path structure, filename, and generated title remain visible.

    Steps to reproduce

    1. Open Codex Desktop and create a new chat.

    2. Prepare a large objective containing a substantial multi-stage task.

    3. Copy and paste the objective into the composer as the first message of the new conversation.

    4. The objective must be large enough that Codex no longer represents the full pasted text inline and instead stores it as an attached file.

    5. Select Goal mode before sending the message.

    6. Send the Goal.

    7. Codex stores the actual objective in an attachment such as goal-objective.md.

    8. The visible first user turn becomes an internal wrapper similar to:

      Read the Codex goal objective file at <local path>\.codex\attachments\<id>\goal-objective.md before continuing.

    9. Inspect the conversation title in the left sidebar and in the thread header.

    Actual behavior

    The conversation is automatically titled:

    Read Codex goal objective

    The title describes the internal instruction used by Codex to locate and load the Goal objective, not the actual task the user asked Codex to perform.

    The underlying Goal can contain a detailed multi-stage engineering objective with enough semantic information to produce a useful title, but that content is not reflected in the conversation name.

    Expected behavior

    For a Goal-first conversation, the generated thread title should be derived from the semantic contents of the actual Goal objective.

    Internal transport instructions such as:

    Read the Codex goal objective file ... before continuing.

    should never become the user-visible title of the conversation.

    The title-generation path should resolve the Goal objective and derive a concise human-readable title from that content.

    Why this matters

    Long-running Goals are specifically used for large tasks that may continue across many turns and multiple implementation stages.

    The Goal itself is therefore the best description of the purpose and identity of the thread.

    If every sufficiently large Goal instead receives a generic title such as:

    Read Codex goal objective

    multiple Goal threads become difficult to distinguish in the sidebar, and the user has to manually rename them after creation.

    It also leaks an internal implementation detail into the user-facing UI: the attachment-loading wrapper becomes the semantic identity of the conversation even though it exists only to transport the real objective to the agent.

    Relationship to this issue

    This appears to be the same underlying class of problem described in this issue: title generation is using the serialized first-turn / attachment wrapper rather than the user's actual request.

    The important difference in this reproduction is that this is not caused by an arbitrary file manually attached by the user.

    It occurs through Codex's own built-in Goal workflow:

    1. The user submits a large Goal.
    2. Codex itself stores the Goal in goal-objective.md.
    3. Codex itself generates the wrapper telling the agent to read that file.
    4. The title-generation path then uses that wrapper instead of the Goal contents.

    So this behavior can be reproduced using the normal Goal UI without any unusual attachment workflow.

    Suggested title-generation behavior

    A better title-generation path for Goal-first conversations would use the Goal objective itself as the semantic source of the thread name, rather than the transport wrapper around it.

    For example, suppose the submitted Goal is a large multi-stage repository review:

    • Stage 1: inspect the repository structure and relevant subsystems.
    • Stage 2: review implementation quality, dependencies, tests, and packaging.
    • Stage 3: prepare a structured report.
    • Stage 4: use the report to investigate selected external references or documentation.
    • Stage 5: produce the final recommendations.

    The exact Goal may be much larger and may be stored internally in goal-objective.md, but after the agent reads that objective, Codex has enough semantic context to derive a useful title.

    Reasonable generated titles for that example could be:

    Repository audit

    Repository review

    Repository review and report

    or, if the Goal itself has an explicit stage-oriented identity:

    Repository audit — Stage 1-5

    The important property is that the title should describe the actual user objective, not the mechanism used to deliver it to the agent.

    A possible implementation would be:

    1. If the first turn is a Goal wrapper that references goal-objective.md, resolve/read the Goal objective before generating the thread title.

    2. Generate the title from the objective content, using the same kind of concise semantic summarization used for normal conversation titles.

    3. If the Goal contains an explicit short name, heading, milestone, or stage identifier, prefer that signal when it produces a useful human-readable title.

    4. Never use internal transport text such as Read the Codex goal objective file ... before continuing as the final user-visible title.

    5. If semantic title generation fails, fall back to a safe generic title such as Goal, Repository audit, or another objective-derived fallback rather than exposing the attachment wrapper.

    This would make Goal threads much easier to identify in the sidebar, especially when several long-running multi-stage Goals are active at the same time.

    Screenshot

    Screenshot attached.

    The screenshot shows that:

    • the first turn was Sent as goal;
    • the visible first turn is the generated goal-objective.md wrapper;
    • the sidebar title is Read Codex goal objective;
    • the thread header is also Read Codex goal objective;
    • the actual Goal contents are not represented in the generated title.
    Image
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions