Windows PowerShell runner fails with non-ASCII characters in user profile name or merge request title

Summary

GitLab Runner on Windows with PowerShell executor fails during the "Getting source from Git repository" phase when the user's GitLab profile full name or merge request title contains non-ASCII characters (e.g., Korean, Chinese, Japanese, etc.). The generated PowerShell script has encoding issues causing syntax errors.

Environment

  • GitLab.com (SaaS)
  • GitLab Runner version: 16.8.0 and 18.8.0 (both affected)
  • Runner executor: shell (PowerShell)
  • Runner OS: Windows
  • Runner registered with tags: dps-runner

Steps to reproduce

  1. Set your GitLab profile full name to contain non-ASCII characters (e.g., Korean: 김민경)
  2. Create a merge request (optionally with non-ASCII characters in the title)
  3. Run a CI/CD pipeline on a Windows runner using PowerShell executor
  4. Pipeline fails at "Getting source from Git repository" phase

What is the current behavior?

The runner generates a PowerShell script with improperly encoded characters, causing parser errors:

��ġ ��:340 ����:8

  • $MODE="development"

�� �Ǵ� ������ ����ġ ���� 'development" ... ���ڿ��� " �����ڰ� �����ϴ�.

The double quote characters " are not recognized, causing "String terminator is missing" and "Unexpected token" errors in Korean (which are themselves garbled due to encoding issues).

What is the expected behavior?

Non-ASCII characters in user profile names and merge request titles should be properly escaped or encoded when generating PowerShell scripts for Windows runners. The pipeline should execute successfully regardless of the character set used in user metadata.

Workaround

Change GitLab profile full name to use only ASCII characters (e.g., English).

Additional context

  • This issue started occurring around early January 2026
  • Other users with ASCII-only profile names can run the same pipeline successfully
  • The same runner and configuration worked correctly before this date
  • Tested with both GitLab Runner 16.8.0 and 18.8.0 - both exhibit the same behavior
  • Changing shell executor to pwsh or cmd did not resolve the issue

Possible root cause

The user's full name or MR title appears to be injected into the generated PowerShell script without proper encoding, breaking the script's string literals and causing cascading parse errors.

Edited by 🤖 GitLab Bot 🤖