Can't see any change after i import workflow from file

Thanks for providing these details!

I did now manage to reproduce the problem you have described on Windows when trying to import files via n8n import:workflow --separate --input=test that were previously exported via n8n export:workflow --all --separate --output=test:

The same command works fine on Linux:

Based on this I suspect this could be a problem with the CLI not looking in the right path here. I’ll take a closer look this afternoon and see if I can come up with a workaround here.

Hey @MutedJam,

Had a quick play here on a Windows VM and it looks like the problem is around here: n8n/workflow.ts at 7a37f73eaed32e88123dfcc48847f42b1cfcf193 · n8n-io/n8n · GitHub

If I chance later and you have not already done it I will have more of a play.

1 Like

Thanks a lot @jon, I was looking at this on a native machine running Windows 11 and was actually throwing a bunch of console.logs around that statement in the first step. At the moment I am struggling to build n8n and some other applications (working fine in WSL, not on the host OS). I think there’s with the Windows build tools not liking my machine.

This will probably take a while to sort so I might need to revisit this tomorrow :frowning:

To be honest I installed through NPM then looked in the NPM package files and edited it that way so I didn’t need to recompile, Did the same thing with the console.log() to see what was going on.

So it seems the package fast-glob is expecting forward slashes, even on Windows. When replacing these strings the import does indeed work:

if (flags.separate) {
    const input = flags.input.replace(/\\/g, '/');
    const files = await glob(
        `${input.endsWith('/') ? input : input + '/'}*.json`,

(ignore the lines above “Succesfully imported 2 workflows.”, that’s just my console.log)

Though such a replacement might have other implications, not sure if any file systems allow backslashes in path names. I’ll think some more about this tomorrow and will either propose a PR or hand this over as a bug in more capable hands depending on how that thought process ends :wink:

1 Like

I would maybe use process.platform to get the OS and then use the result of that for the path setting.

1 Like

I’ve raised a PR using process.platform as suggested by Jon: 🐛 CLI: Add windows support to import:workflow --separate by that-one-tom · Pull Request #2441 · n8n-io/n8n · GitHub. This works on both Windows and Linux.

Let’s see what the team says :slight_smile:


Fix got released with [email protected]

thanks, when do you plan to upload to git?

@Asaf_Shay it is already merged and is in version 150 which you should be able to update to now by pulling the latest docker image.

If you are running from source it has been available for about 2 days.


thanks, very helpful


still not working

I have only one json file

Hey @Asaf_Shay,

What version are you running now?

I just clone from master

Do you have that test5 folder in that bin directory?

yes i have

I am not sure why it still wouldn’t be working on your machine, can you send a screenshot shot of the dir command output in the test5 folder?

this my folder (i added all my workflows)

Might need @MutedJam to take a peek when he is around, I don’t have access to a windows machine today.

My first thought would that you might not be calling the right binary when typing n8n (at least in my PowerShell instance, typing n8n would refer to the n8n desktop app’s script or the global npm installation of n8n).

@Asaf_Shay when inside your repository folder, could you try calling the import logic like in the PR example? E.g. .\packages\cli\bin\n8n import:workflow --separate --input=C:\Users\Tom\Desktop\test (so with the path to the binary you want to run and also the full input path)?