Oh okay that I hadn't caught. Manual install instructions still apply.
You must also download and install the micronucleus drivers themselves if you have not already done so. I forget how you get the IDE to recognize the path to the upload tool. I'd probably try uploading with verbose output enabled, see what the path to the upload tool it was trying to use was, and create it there.
https://azduino.com/bin/micronucleus/micronucleus-cli-2.5-azd1b-x86_64-mingw32.zip
still applies
But you will never get a COM port. You should not expect to. It is a Micronucleus board, it appears for 8 seconds as a USB device of it's own kind when plugged in and then the sketch starts running and it vanishes as a USB device. During those 8 seconds it can be programmed. What I wrote above about it maybe being tricky to get the uploader where you want it. I think on the t88 boards, reset pin resets also run the bootloader. (ATTC 2.0.0 will have like 10 options for entry conditions to fine tune your micronucleus upload experience to meet your application needs)
The Micronucleus boards do not project as a serial port (in fact, they cant even do virtual serial port - you basically can't do anything USB from within Arduino. The digispark people tried really hard and were not terribly successful. VUSB doesn't really work in the Arduino context (Interrupt driven bitbang USB is provably hopeless on classic AVRs, theoretically possible on a modern AVR , maaaybe (maybe not at 24 MHz, but those things overclock like a dream)
Even that would require sacrifices and would need a lot of work in ASM to realize) - but why would anyone bother, what with the DU-series coming out potentially sooner than most expect carrying real proper native USB and coming in pincounts from 14 to 32).
On classic AVR, the only place VUSB has seen use, it's only viable in the bootloader context, or a raw C non-arduino context (doesn't matter if you use arduino to compile it, just that you don't use any part of the core or arduino API) and override main and then doing every single thing yourself, with the first, second and third priorities being keep USB working). That's what they did for the micronucleus bootloader, and written in the way it is, It's rock solid, better than optiboot (optiboot can brick on tinyAVR if there's a power glitch or reset at a bad time, micronucleus does this correctly and does not) - but the only reason it works is that they have sorta built the whole thing around the scaffolding of needing to keep USB happy (and because they wrote it understanding the flash erase hazard that trips up optiboot)