TCC & IDE & TCMD all call GetCommandLine() once, in exactly the same way:
CAtlString strCommandLine = GetCommandLine();
There's no pointer to the text, so there is no subsequent possibility for anyone to modify what GetCommandLine() points to. Barring catastrophic failures in C++, ATL, Windows, and Intel's hardware. (Okay, we're all used to the catastrophic failures coming from Intel ...)
When I run BDEBUGGER or IDE (both internal TCC commands that generate a custom command line to pass to IDE.EXE), I see IDE.EXE in the task manager with the command line passed to it by TCC. Debugging batch files or loading new files in tabs doesn't affect the fixed result shown by task manager. And the text shown in task manager is not necessarily the same as returned by GetCommandLine() inside IDE.EXE.
Also (this is Windows, not TCC / IDE / TCMD) the executable argument is not necessarily returned as the first argument by GetCommandLine(). (That's been happening for at least 20+ years, back to NT 3.1.) And what is returned by GetCommandLine() depends on exactly how CreateProcess is called (there's several different ways to pass the arguments). And Windows will on its own sometimes rewrite the arguments passed to CreateProcess (for example, to add paths).
Looking for the executable name in the string returned by GetCommandLine() is fruitless. If that's what you're looking for, you should be using GetModuleFileName().