Azure App Service (Kudu) - Why is the Current working directory path not matching the system path?

In Azure App Service the “Current working directory” shown in Kudu is simply the process working directory for the worker process at the time it was started. It does not have to match the system directory and it can legitimately point into a site extension folder such as the Application Insights agent.

On Windows, the working directory is just a process property (Environment.CurrentDirectory) that can be set by the process that launches the app or changed at runtime. It is independent of the system directory (C:\Windows\system32) and of the drives that App Service exposes for content and logs (for example %SystemDrive%, %ResourceDrive%, and the network content share).

This path is mainly used when code or tools rely on relative paths. Windows path normalization applies the current directory to relative paths that are not fully qualified, so any relative file access from that process will be resolved against this working directory. If the app uses fully qualified paths or the recommended environment variables (%SystemDrive%, %ResourceDrive%, or the UNC content paths), the value shown here does not affect behavior.

Changing it to C:\Windows\system32 is neither required nor recommended for App Service apps. Instead, code should:

• Use environment variables such as %SystemDrive% and %ResourceDrive% rather than hard‑coded paths.
• Avoid relying on the process working directory for locating content; use explicit, fully qualified paths or framework features like IHostEnvironment.ContentRootPath in .NET.

The system directory (C:\Windows\system32) remains what Windows reports as the system folder regardless of the current working directory.

References:

• Operating system functionality in Azure App Service
• Environment.CurrentDirectory Property
• File path formats on Windows systems
• ContentRootPath for apps launched by Windows Shell
• path