Codex Desktop: support task-scoped named values with explicit model visibility

What variant of Codex are you using?

Codex Desktop / unified ChatGPT desktop app.

What feature would you like to see?

Add a small task-scoped value store for user-supplied values that are repeatedly needed during one Codex task, with an explicit distinction between values used only for local UI substitution and values the user deliberately allows Codex to use as task context.

A common example is a path, port, branch name, hostname, output directory, or other task-specific value. Today, if the assistant needs an exact value repeatedly, the user generally has to either re-enter it in later commands or send a chat message whose only purpose is to disclose and define that value.

A useful interaction would be:

PROJECT_PATH = C:\Users\me\Documents\my-project

Use:
○ This rendered block only
○ Remember locally for this task
○ Allow Codex to use this value for this task

The exact UI is not prescribed; the important part is the scope and visibility contract.

Proposed behavior

1. Local task value

A user can give a named value such as PROJECT_PATH and choose Remember locally for this task.

Future assistant output containing an intentionally marked PROJECT_PATH slot can then be prefilled by the client without requiring the user to type the value again.

In this mode, remembering the value should not by itself create a user message or add that value to model context.

This would pair naturally with #44911, which requests fillable placeholder spans inside generated code blocks, but task-scoped values should remain a separate feature so the code-block UI improvement does not depend on persistence or context changes.

2. Explicit Codex-visible task value

The user can separately choose Allow Codex to use this value for this task.

That grants permission for the value to be supplied as structured task context where appropriate, without requiring a synthetic chat message such as "my project path is ..." solely to establish a reusable parameter.

The UI should be explicit that a Codex-visible value may be sent to the model/backend or exposed to relevant task tooling. "Not shown as a normal chat message" must not be presented as equivalent to "not disclosed to OpenAI".

There should be no automatic promotion from local-only to Codex-visible.

Inspectability and control

Task values should be inspectable rather than becoming mysterious hidden state. A compact Task Values view, popover, or equivalent could show:

• name;
• current value;
• scope (local only or available to Codex);
• edit action;
• revoke/clear action.

The initial implementation can be limited to the current task/thread. Ending or clearing the task should end their scope unless a later feature explicitly adds broader persistence.

Why this is useful

This solves two related pieces of friction:

1. Values needed only to customize generated commands can be entered once and reused locally.
2. Values Codex genuinely needs for later reasoning can be provided through an explicit scoped control instead of creating conversational noise solely to define a variable.

It also makes disclosure more intentional: the user can distinguish "use this value to fill my copied command" from "Codex itself may use this value while working on the task."

Acceptance criteria

1. A user can create/edit/clear a named value scoped to the current task.
2. Local-only values can prefill matching intentional UI slots without automatically becoming user-message or model context.
3. Making a value available to Codex requires an explicit user action.
4. The UI clearly identifies whether a value is local-only or Codex-visible.
5. Revoking Codex visibility prevents the value from being supplied as such in later turns.
6. Task values do not silently propagate into unrelated conversations/tasks.
7. Existing transcript content remains unchanged; task values are structured state, not retroactive message edits.

Scope / non-goals

This request is intentionally not a general expression language or configuration system. It does not require:

• shell-command substitution;
• arbitrary expression evaluation;
• automatic import of environment variables;
• project/global persistence;
• cross-conversation memory;
• credential/secret management;
• automatic discovery of local filesystem values;
• hiding from the user what information the model can access.

Sensitive credential storage should remain a separate product/security problem with stronger controls.

Related issues

• #44911 — fillable placeholders inside generated code blocks. That issue is deliberately UI-only; this request is the optional task-scoped state layer that could later prefill those slots.
• #2890 — completed support for parameters in custom prompts. This demonstrates value in explicit user-supplied parameters, but is a different surface and lifecycle.
• #5019 — broader dynamic expressions/command substitution in custom prompts. This request is intentionally narrower: named user-entered values, no expression evaluation, and explicit per-task visibility.

I did not find an existing request for a task-scoped value with a user-visible distinction between local substitution and model-visible task context.

The issue names no implementation files, tests, or entry points; begin by locating the Codex Desktop task/thread state and the UI surface for task values. Done means task-scoped named values support local-only and explicitly Codex-visible modes, inspection, editing, revocation, and clearing while meeting all listed acceptance criteria.