Howdy-

Hmm, that shouldn't be the case. A few things to consider here:
-----------------------------------------------
0) What version of AFNI are you using ("afni -ver")? I assume it shouldn't matter, but let's be sure.

1) When you run Clusterize in the GUI and click "Rpt" -> "SaveMsk", it actually makes a call to 3dClusterize using the parameters you have specified (olay and thr bricks, NN value, threshold, sidedness, etc.). For example, when I ran something similar to your command in the AFNI_data6/afni/ Bootcamp directory, namely for the "func_slim*" statistical dset, and then you will see in the terminal what it has run, for example:

3dClusterize -nosum -1Dformat -inset /home/ptaylor/AFNI_data6/afni/func_slim+orig.HEAD -idat 5 -ithr 6 -NN 1 -clust_nvox 40 -bisided -3.3133 3.3133 -mask_from_hdr -pref_map Clust_mask

Checking that out should reduce the ambiguity; note that the internal p-to-stat calculation has been done here---you can check this with the p2dsetstat command:

p2dsetstat -inset "func_slim+orig[6]" -bisided -pval 0.001

... which here outputs:

++ Found input file : func_slim+orig[6]
++ OK stat type     : fitt
++ BRICK_STATAUX    : 0 3 1 430
++        params    : 430
++ Final stat val   : 3.3133

(you could put "-quiet" for scripting purposes). So, this all looks consistent.

2) Note that 2sided and bisided are very similar but importantly different. In my case above, in the Clusterize panel, I left "bisided" as on here, so that positive-data-voxels and negative-data-voxels don't cluster together. In general, it is hard not to see that "bisided" would be more appropriate than "2sided", where in the latter opposite-sided effects can join forces to form a cluster (though proximity in that case doesn't seem to warrant considering them as part of the same cluster). *But*, if you really do want 2sided and not bisided clustering, then after selecting "Bisided -> no" in the initial Cluster parameter panel, the output SaveMsk would show this:

+ 3dClusterize -nosum -1Dformat -inset /home/ptaylor/AFNI_data6/afni/func_slim+orig.HEAD -idat 5 -ithr 6 -NN 1 -clust_nvox 40 -2sided -0.0001 0.0001 -mask_from_hdr -pref_map Clust_mask

Note that the p2dsetstat calculation for 2sided or bisided is the same, so:

p2dsetstat -inset "func_slim+orig[6]" -2sided -pval 0.001

produces the identical-to-above:

++ Found input file : func_slim+orig[6]
++ OK stat type     : fitt
++ BRICK_STATAUX    : 0 3 1 430
++        params    : 430
++ Final stat val   : 3.3133

3) A more subtle point in this: I was not loading in a mask dset for 3dClusterize here; there isn't a way to do that on-the-fly in the GUI. *However*, if you notice in the SaveMsk output in each case above, there is an option being used: "-mask_from_hdr". From the 3dClusterize help, we see what this means:

-mask_from_hdr :If 3dClustSim put an internal attribute into the
                 input dataset that describes a mask, 3dClusterize will
                 use this mask to eliminate voxels before clustering,
                 if you give this option (this is how the AFNI
                 Clusterize GUI works by default).  If there is no
                 internal mask in the dataset header, then this
                 doesn't do anything.

The logic for doing this: to do clusterizing, you typically run 3dClustSim or something to determine a cluster threshold; using 3dClustSim, you need to imput a mask to define the volume within which to estimate the spatial smoothness of noise; that is an important mask for further calcs, so let's keep it close by... even in the header, so it doesn't get lost.
... and to check if there really is a mask attached to the dset, you can ask 3dClusterize to output it:

-out_mask OM   :specify that you wanted the utilized mask dumped out
                 as a single volume dataset OM.  This is probably only
                 really useful if you are using '-mask_from_hdr'.  If
                 not mask option is specified, there will be no output.

or you can check the attributes like this:

3dAttribute AFNI_CLUSTSIM_NN1_1sided func_slim+orig.

... and indeed, func_slim* here does have one. So, if on a command line test I didn't include the mask, I might run into troubles. I don't know that this is your case here, though.
-----------------------------------------------

OK, so, after all that (probably a longer reply than you wanted!), to check that things are consistent, can you please use Clusterize -> Rpt -> SaveMsk to dump out the 3dClusterize command from the GUI, and see what is being output? You can verify with that and p2dsetstat that the p-to-stat calc is consistent with your command line call, too.

Please let me know how that goes, and if things seem consistent. For me, running this in the command line:

3dClusterize -inset func_slim+orig. -ithr 6 -idat 5 -NN 1 -bisided p=0.001 -clust_nvox 40 -pref_map OUT_CMDLINE_map_bisided.nii -out_mask OUT_CMDLINE_mask_bisided.nii -mask_from_hdr -overwrite

... matched with the GUI results after thresholding with p=0.001, opening the Clusterize panel and setting NN=1, clustsize=40, and leaving Bisided->yes, and then dumping things out. But note that I had to include the "-mask_from_hdr" explicitly in my command line call.

--pt