[Windows][model behavior] Codex repeatedly adds an extra backslash after `%~dp0` in generated batch files

Summary

When Codex creates or edits Windows batch files, it repeatedly treats %~dp0 like a normal directory variable that has no trailing separator and adds another backslash before a relative path.

This produces code such as:

call "%~dp0\build.bat"
set "CONFIG=%~dp0\config.ini"
pushd "%~dp0\.."

However, in cmd.exe, %~dp0 already expands to the drive and path of %0, and the path component ends with a backslash. If the script is located at C:\Project\scripts\run.bat, then:

%~dp0  ->  C:\Project\scripts\

The generated examples therefore expand to non-canonical paths such as:

C:\Project\scripts\\build.bat
C:\Project\scripts\\config.ini
C:\Project\scripts\\..

Environment

• Codex desktop app: 26.721.4979.0
• OS: Windows 11, version 10.0.26200
• Target language/runtime: Windows batch files executed by cmd.exe
• Observed while asking Codex to create or modify .bat / .cmd scripts in Windows-first projects

Minimal reproduction

Ask Codex:

Create a Windows batch file that calls build.bat from the same directory as the current script. Use %~dp0 so it works regardless of the caller's current working directory.

Codex frequently generates:

@echo off
call "%~dp0\build.bat"

Expected output

@echo off
call "%~dp0build.bat"

The same rule applies when appending any relative child path:

set "CONFIG=%~dp0config.ini"
pushd "%~dp0.."

If a variable is explicitly normalized to remove the trailing separator first, adding a backslash later is valid, but that is a different pattern.

Why this is a real correctness issue

Many Windows filesystem APIs and commands silently normalize duplicate separators in the middle of a path, so the generated script may appear to work during a simple test. That tolerance hides the mistake and likely makes it less visible to automated evaluation.

The output is still incorrect and non-canonical. It can cause failures or mismatches in tools that validate, serialize, compare, quote, or forward path strings without applying the same normalization. It also causes repeated review and correction of generated Windows scripts.

This is deterministic cmd.exe syntax, not a project-specific style preference.

Expected Codex behavior

Codex should model %~dp0 as a value whose expansion already ends in \:

• Append a child directly: %~dp0file.ext
• Append a parent directly: %~dp0..
• Do not generate %~dp0\file.ext or %~dp0\..

A focused Windows batch generation evaluation or lint check could flag the literal pattern %~dp0\ when it is used to prepend a relative path.

Related issue

• #9581 reports the broader class of recurring Windows shell/model-behavior regressions, but it does not cover this specific %~dp0 rule.