VBA CurDir & ChDir in Excel — Why a Relative Path Lands in the Wrong Folder

TL;DR — A relative path (a name with no drive, like "Reports") is resolved against CurDir, Excel's current working directory — which is not your workbook's folder and changes whenever a File Open dialog points somewhere new. So MkDir "Reports" or Open "data.csv" can land in a different place every run. Anchor every path to ThisWorkbook.Path.

Sub WhereDoesThisGo()
    MkDir "Reports"                              ' created under CurDir — often NOT next to the workbook
    MkDir ThisWorkbook.Path & "\Reports"         ' created next to THIS workbook, every time
End Sub

This is the bug behind a whole family of confused reports: "my macro created the folder in the wrong place," "it saved the file to Documents," "it worked yesterday and today it doesn't." None of them are random. They all trace to one fact people never think to question — that a relative path in VBA is resolved against a working directory Excel manages for you, and that directory is not where you assume it is. Understand CurDir, and every one of those bugs becomes preventable with a single habit.

What you'll learn

• The mental model — a relative path means nothing until it is resolved against CurDir
• Why CurDir is not ThisWorkbook.Path, and where it actually points
• How a File Open dialog silently changes CurDir mid-macro
• Why ChDir cannot change the drive, and why ChDrive is a separate statement
• Why ThisWorkbook.Path is empty for a workbook that was never saved
• The one habit that removes the whole class of wrong-folder bugs

The mental model: a relative path is resolved against CurDir

The key insight is that VBA has two kinds of path, and they behave completely differently:

• Absolute — starts with a drive or root: "C:\Reports\March.xlsx". It means exactly one place.
• Relative — no drive, no leading \: "Reports" or "data\in.csv". It means "relative to the current directory," and VBA fills in the rest from CurDir.

CurDir is a function that returns that working directory — CurDir for the current drive, or CurDir("D") for a specific one. Every statement that takes a path — MkDir, RmDir, Open, Kill, Name, Dir — resolves a relative path against CurDir. So the question "where did my folder go?" is really "what was CurDir at the moment the statement ran?" — and that is a much less obvious question than it sounds.

CurDir is not ThisWorkbook.Path

Here is the misconception at the root of it all: people assume the "current directory" is the folder the workbook lives in. It is not. They are two unrelated values:

Debug.Print CurDir              ' Excel's working directory — often C:\Users\You\Documents
Debug.Print ThisWorkbook.Path   ' where THIS workbook is saved — e.g. D:\Projects\2026

CurDir starts as whatever Windows handed Excel at launch (frequently your Documents folder) and has no connection to where you opened your workbook from. So MkDir "Reports" does not create a folder next to your file — it creates one under CurDir, which could be anywhere. ThisWorkbook.Path, by contrast, always points at the folder containing the workbook running the code. Whenever you mean "next to my workbook," that is the property you want — never CurDir.

A File Open dialog silently changes CurDir

The reason wrong-folder bugs are intermittent — fine yesterday, broken today — is that CurDir does not hold still. Windows updates it whenever the user (or your own code) browses a folder in a file dialog:

Dim f As Variant
f = Application.GetOpenFilename          ' user browses to D:\Client\Inbox and picks a file
' CurDir is now D:\Client\Inbox — it moved, invisibly
MkDir "Reports"                          ' creates D:\Client\Inbox\Reports, not where you meant

Nothing in your code said "change directory," yet CurDir moved because the dialog set it. Any relative path after that point resolves against the new location. This is why the same macro writes to a different folder depending on what the user clicked five minutes earlier — a genuinely invisible dependency, and an unanswerable support ticket unless you know CurDir is the moving part.

ChDir changes the folder — but not the drive

If you do want to set the working directory deliberately, ChDir is the statement — but it has a trap that catches almost everyone: ChDir changes the current folder, not the current drive.

ChDir "D:\Data"     ' sets D:'s default folder to \Data — but you are STILL on drive C:
CurDir              ' still returns C:\... — the drive never changed

To actually move to another drive you need ChDrive first, and it is a separate statement:

ChDrive "D"         ' switch the current drive to D:
ChDir "D:\Data"     ' now set the folder on D:

This split — one statement for the drive, another for the folder — is a leftover from DOS, where each drive remembered its own current directory. It is exactly the kind of surprise that makes "just set the working directory" fragile. Which points at the real fix: don't manage a working directory at all.

The habit that removes the whole class of bugs

Every wrong-folder bug above disappears if you never use a relative path. Build an absolute path from ThisWorkbook.Path and hand that to every file statement:

Dim base As String
base = ThisWorkbook.Path & Application.PathSeparator     ' e.g. "D:\Projects\2026\"
MkDir base & "Reports"                                    ' always next to the workbook
Open base & "data.csv" For Output As #1                   ' same anchor, no CurDir dependency

Two details make this robust. Use Application.PathSeparator rather than a hard-coded "\" so the code does not assume a separator, and mind the trailing separator so you never produce ...2026Reports by accident. With every path anchored to ThisWorkbook.Path, CurDir becomes irrelevant — it can roam wherever the dialogs push it and your folders still land exactly where you meant.

One edge case to guard: ThisWorkbook.Path is an empty string for a workbook that has never been saved. If a macro can run before its first save, check If ThisWorkbook.Path = "" Then and prompt for a location rather than building a broken path from nothing.

The honest verdict: anchor to ThisWorkbook.Path, never to CurDir

CurDir is worth understanding precisely so you can stop depending on it. Four rules:

• A relative path follows CurDir → and CurDir is Excel's roaming working directory, not your workbook's folder.
• A File Open dialog moves CurDir → so relative paths are intermittently wrong; never trust the working directory to be where you left it.
• ChDir won't change drives → you need ChDrive first; both are a sign you are managing state you shouldn't have to.
• Anchor to ThisWorkbook.Path → build absolute paths with Application.PathSeparator, guard the unsaved-workbook case, and the wrong-folder bug is gone for good.

This is the thread that ties the folder tools together: MkDir and RmDir are only as reliable as the path you hand them, and a relative path hands your fate to CurDir. Give them an absolute path built from ThisWorkbook.Path, and both statements do exactly what you expect, every run.

How ExcelMaster helps

Getting a path right means knowing that CurDir is not your workbook's folder, that a File Open dialog moves it without warning, that ChDir cannot change drives, and that ThisWorkbook.Path is empty until the workbook is saved — four traps behind every "it created the folder in the wrong place" report.

ExcelMaster writes paths that land where you mean. Describe the job — "save the export next to this workbook," or "build the output folder in the project directory" — and it produces an absolute path anchored to ThisWorkbook.Path with Application.PathSeparator, never a relative path that depends on CurDir, and it guards the unsaved case. You describe where the file should go; it writes the path that puts it there on every run.

Frequently asked questions

What does CurDir return in VBA?

CurDir returns Excel's current working directory — the folder that relative paths are resolved against. CurDir gives the directory on the current drive; CurDir("D") gives it for drive D. It is usually whatever Windows set when Excel launched (often your Documents folder) and has no connection to where your workbook is saved, so do not use it to mean "next to my file."

Why does my VBA macro create the folder or save the file in the wrong place?

Because you used a relative path, and VBA resolved it against CurDir instead of your workbook's folder. CurDir is Excel's working directory, and a File Open dialog silently changes it, so the same relative path lands in different folders on different runs. Build an absolute path from ThisWorkbook.Path — ThisWorkbook.Path & "\" & "Reports" — and the location stops depending on CurDir.

What is the difference between CurDir and ThisWorkbook.Path?

CurDir is Excel's roaming working directory — where relative paths resolve, changeable by any file dialog. ThisWorkbook.Path is the folder where the workbook running the code is saved, and it does not move. When you mean "next to this workbook," always use ThisWorkbook.Path; use CurDir only when you genuinely want the working directory, which is rare.

Why doesn't ChDir change the drive in VBA?

Because ChDir changes only the current folder, not the current drive — a holdover from DOS, where each drive kept its own current directory. ChDir "D:\Data" while you are on C: sets D:'s default folder but leaves you on C:. To switch drives, call ChDrive "D" first, then ChDir "D:\Data". In practice it is simpler to avoid the working directory entirely and use absolute paths.

Why is ThisWorkbook.Path empty?

ThisWorkbook.Path returns an empty string when the workbook has never been saved — an unsaved workbook has no folder yet. If a macro might run before the first save, check If ThisWorkbook.Path = "" Then and prompt the user for a location (with Application.GetSaveAsFilename) instead of building a path from an empty string, which would produce a relative path resolved against CurDir.

Tested in

Tested in: Excel 365 (Windows 11), VBA 7.1 — last verified 2026-08-23.

Related guides: VBA MkDir · VBA RmDir · VBA Dir · VBA Open Workbook · VBA Check If File Exists