I wasn't sure whether to report this as a Cmder or Clink issue, but since the error referred to the cmder\vendor\clink.lua file and not something in the cmder\vendor\clink directory, I decided to post it here.

An astute observation, thank you! Yes, the cmder\vendor\clink.lua script is part of Cmder, not part of Clink.

It turns out, though, that this reveals two issues: one in Clink itself + one in Cmder.

Issue in Clink:

• Prior to Clink v1.1.32, Cmder didn't work with Clink set to autorun. Or rather, Cmder ended up hosting a plain cmd+Clink without any of Cmder's extensions (config, scripts, prompt, etc).
• In Clink v1.1.32, I made it so when Cmder tries to inject Clink into a cmd that already injected Clink via autorun, Clink forwards Cmder's inject parameters to the already-injected Clink so that Cmder can work.
• But I missed forwarding the profile directory (%cmder_root%\config). So Cmder starts properly now, but the profile directory is wrong, so Cmder's config file isn't found.

Fix in Clink: Forward the profile directory.

Issue in Cmder:

• The cmder\vendor\clink.lua script is relying on using Cmder's profile directory. It's very easy and reasonable in Clink for a user to override the profile directory (though in the reported case here it's only accidentally overridden due to a bug in Clink).
• So if/when any user intentionally overrides the profile directory, it will break the Cmder extensions to Clink and cause similar errors.
• Issue when upgrading Cmder: Relying on the config file existing means that adding any other settings to the config file is very difficult to do without overwriting any customizations users have made.

Fix in Cmder: Add default logic to not rely on the cmder_prompt_config.lua file.

Then there's no need for Cmder to initially create the cmder_prompt_config.lua file (but it could create a placeholder file named differently e.g. with a .default extension that contains sample settings and instructions how to copy the placeholder file to make a real file). And if Cmder no long has to create/update the cmder_prompt_config.lua file then that solves the upgrade issue.

There are several approaches for adding default logic:

1. At the top of clink.lua it could simply say uah_color = "\x1b[30m" (etc). And then when Clink loads the cmder_prompt_config.lua file afterwards, the config file would override the initial default. This is the simplest, but is not as safe as option 2.
2. Another approach could be to use a function e.g. clink.lua line 90 could say prompt = get_uah_color() .. etc and make the get_uah_color() function be something like local function get_uah_color() return (uah_color or "\x1b[30m") end. That factors the logic into a single place and has the added bonus that if a script accidentally sets uah_color = nil then it will fall back to using a default. It's a little safer.
3. Or if a variable is used only once, it might be reasonable to embed a default inline such as prompt = (uah_color or "\x1b[30m") .. etc. That's less initial effort than option 2, but can get unwieldy.

I've published Clink v1.2.5 that should fix this autorun-vs-Cmder issue.

@daxgames It's still worth addressing the Cmder part of the issue (see above).

Please test this

Please test this

Looking good! I also tried a Clink 1.2.5 manual install with build 1114 and that combo fixed the reported bug too. I see this latest one, build 1119, has Clink 1.2.5 with it as well (at least, according to the .cmderver file in %cmder_root%\vendor\clink). Both scenarios (build 1114 with manual install of Clink 1.2.5 and 1119 "straight up") look good.

Cool