Windows app: user-requested Set-Clipboard rejected before execution after earlier clipboard writes succeeded

Codex Windows: explicitly requested clipboard write rejected before execution after earlier clipboard writes succeeded

What version of the Codex App are you using?

Windows installed package OpenAI.Codex, version 26.908.9136.0, verified using
Get-AppxPackage. The bundled CLI version was not separately collected.

What subscription do you have?

Not collected for this report.

What platform is your computer?

Windows 11; OS version string Microsoft Windows NT 10.0.26200.0.
Native PowerShell 7.6.5, not a WSL shell.

What issue are you seeing?

An explicitly requested local clipboard write was rejected by the command tool
before the PowerShell process ran. Earlier in the same conversation, Set-Clipboard
followed by Get-Clipboard verification succeeded. Those earlier writes contained
different text, so this is not a controlled comparison of identical commands.

The rejected action was to copy a prepared public software announcement into the
Windows clipboard for the user to paste manually. No message was to be sent, no
website submitted, and no credentials or private clipboard content uploaded.

The user reports this is approximately the third similar interruption. This report
documents the latest observed rejection, not three independently reproduced cases.

The tool returned this error shape (executable path/command body redacted):

exec_command failed: CreateProcess { message: "Rejected(\"...pwsh.exe -Command ... rejected: blocked by policy\")" }

The actual rejection included a quoted representation of the command, with its
long text body truncated. It did not expose a matched rule, specific rationale,
policy owner, correlation ID for the rejection, or an actionable approval path.
There was no PowerShell parser/runtime error because execution was rejected first.

What steps can reproduce the bug?

Observed sequence, September 17, 2026:

1. Ask Codex in the Windows desktop app to copy prepared text to the local clipboard.
2. Earlier requests succeeded using native Set-Clipboard and read-back verification.
3. Later request: copy a roughly 2–3 KB multiline public announcement containing
   punctuation, bullet characters and HTTPS links. The agent invoked exec_command
   through functions.exec using a PowerShell single-quoted here-string, then
   Set-Clipboard, then a Get-Clipboard comparison.
4. The tool rejected the invocation with blocked by policy before process launch.
5. Subsequent read-only checks succeeded: Get-Command resolved both clipboard
   cmdlets from Microsoft.PowerShell.Management; Get-Clipboard -Raw returned normally.
   The current clipboard contents were not included in this report.

Sanitized command structure below; this is an illustrative description of the
failed invocation, NOT a separately reproduced minimal test:

$announcement = @'
[User-approved multiline public announcement, with bullet characters and HTTPS links]
'@
Set-Clipboard -Value $announcement
if ((Get-Clipboard -Raw).Trim() -ne $announcement.Trim()) {
    throw 'Clipboard verification failed'
}
'Announcement copied and verified.'

The user reports making no permission changes. Session metadata reported
danger-full-access with approval_policy never. This does not prove which policy
was evaluated at rejection time or that all command actions must be allowed.

Read-only inspection found no rules directory at the current user's .codex/rules,
the workspace .codex/rules, or the nested project .codex/rules. This does not rule
out other policy sources or prove that a local rules configuration is responsible.

No rejected clipboard write was retried during diagnosis, and no permissions or
safety settings were modified to circumvent the rejection.

What is the expected behavior?

Please investigate whether explicitly user-requested writes of ordinary public
text to the local clipboard are being incorrectly rejected. If such a write is
intentionally restricted, return the enforcing component/reason and a supported
approval or recovery path instead of only blocked by policy.

Please clarify whether message length, Unicode, here-string parsing, command
composition, or another policy input matters. These are questions, not established
causes. The read-only checks do not establish that clipboard writes currently work.

The lack of a diagnostic makes it impossible to tell the user whether to change a
setting, report a regression, or use a supported alternative. It repeatedly
interrupts an otherwise straightforward copy-and-paste workflow.

Related issues and privacy

Searched existing issues for Set-Clipboard, clipboard/policy, and blocked-by-policy
on Windows. Related reports: #43905 and #46012. Neither specifically documents
this authorized clipboard-write case. Please consolidate if the underlying cause
is already tracked; no root-cause equivalence is claimed.

No credentials, clipboard contents, personal paths, screenshots, unrelated project
files, or raw conversation/session logs are attached. This requests investigation
and actionable diagnostics, not disabling safeguards.

Start with the functions.exec to exec_command rejection path described in the report, then compare it with the earlier successful Set-Clipboard and later read-only PowerShell checks. Reproduce using the sanitized multiline clipboard command and determine which component rejects it; done means identifying the enforcing reason and providing actionable diagnostics or a supported recovery path.