Thanks nkast and sqrMin1, both your answers do in fact fix the issue. They also led to me to do a little more debugging and figure out exactly WHY the workingDir command wasn’t working, as it really should address this exact issue.
Turns out, workingDir does fix the issue. Sort of. However, it ONLY works if you call MGCB.exe with the workingDir command coming BEFORE the “@” parameter (which specifies the Content.mgcb file.
Doing some digging in the MGCB code, most if not all of the command line parameters are executed immediately and in the order they are read, instead of being saved off and used in the order where they would have effect. So what was happening is that as soon as the CommandLineParser read my command line arguments, it took the “/@:…/code/project/Content/Content.mgcb” parameter and immediately parsed through that file making a list of ContentItem objects. All of these would use Directory.GetCurrentDirectory() and the relative path in the file to construct the path. However, this path always just refers to wherever MGCB call is coming from. Later, when the /workingDir command gets read, it calls Directory.SetCurrentDirectory(path);. However, this does nothing because the list of ContentItems has already been created and the paths set.
Moving the workingDir to the first parameter does indeed fix the problem where it cannot find the assets. It will find and build them. However, as sqrMin1 mentions, the output directory then breaks because everything still references Directory.GetCurrentDirectory() and combines that with the parameters, and the current directory has been changed to workingDir at this point.
So TLDR:
MGCB is pretty wonky when being called from the command line, and the workingDir parameter is pretty finicky.
It is very weird to send the same parameter multiple times, but the following code DOES work in the command line:
MGCB.exe /workingDir:…/code/project/Content/ /platform:Windows /@:…/code/project/Content/Content.mgcb /workingDir:%~dp0 /outputDir:Content /intermediateDir:ContentTemp
Basically it will set the workingDir to the Content folder, then it will execute the “/@” parameter using that directory and make the list of items to build. Then, the second workingDir parameter will set the path to the path back to where the batch file is so that the output and intermediate dirs. will be properly relative.