--show-airlock-rules is a read-only command by name, but it creates directories on disk.
It resolves both paths through the helpers in _AirlockConfig.cs:
// ShowAirlockRules.cs:39 and :56
var globalRulesPath = AirlockConfig.GetGlobalRulesPath(paths);
var localRulesPath = AirlockConfig.GetLocalRulesPath(paths);
and both of those call Directory.CreateDirectory before handing the path back:
// _AirlockConfig.cs:138
public static string GetLocalRulesPath(AppPaths paths)
{
var path = paths.GetLocalPath(RulesFileName);
var dir = Path.GetDirectoryName(path);
if (!string.IsNullOrEmpty(dir))
Directory.CreateDirectory(dir);
return path;
}
So running --show-airlock-rules in any project leaves an empty .copilot_here/ behind, in a directory the user may only have wanted to inspect. It then prints "Local Config: Not configured", having just created the directory that would hold it.
The mkdir belongs with the commands that write. Splitting the helper into one that resolves a path and one that ensures the directory, and having the display command use the former, keeps the side effect where it's wanted.
--show-airlock-rulesis a read-only command by name, but it creates directories on disk.It resolves both paths through the helpers in
_AirlockConfig.cs:and both of those call
Directory.CreateDirectorybefore handing the path back:So running
--show-airlock-rulesin any project leaves an empty.copilot_here/behind, in a directory the user may only have wanted to inspect. It then prints "Local Config: Not configured", having just created the directory that would hold it.The mkdir belongs with the commands that write. Splitting the helper into one that resolves a path and one that ensures the directory, and having the display command use the former, keeps the side effect where it's wanted.