Maybe I'm doing this wrong, but I don't think this is working?

I modified the customTaskProvider sample to take an 'extra' flag like so:

        {
            "type": "custombuildscript",
            "flavor": "64",
            "flags": [],
            "extra": "${command:workbench.action.files.openFile}",
            "problemMatcher": [],
            "label": "custombuildscript: 64 "
        }

Running the task does bring up the open file dialog but the custom task execution never runs.

If I remove the command argument for extra, the custom command task runs. So it seems like this is halfway fixed?

@rchiodo The fix (9923e8e) solves the bug I had. I use a custom command that shows a quick pick and returns a value, and it works great in insiders.

It seems some builtin commands prevent tasks from starting (e.g. ${command:workbench.action.files.openFile} or ${command:workbench.action.findInFiles}). However this is the case for me even when using ShellExecution so it is probably a separate bug (or intented? I'm not sure what would be the expected result when calling openFile in a task definition).

Thank you for verifying @HampusAdolfsson!

Commands that don't return a string are not supported for variable resolving, so this is intended.