Incongruent tab id between stdout of brave-cli list tabs

[TunnelThruTime]

A curiosity – Each time that I run the command brave-cli list tabs the ids are different.

At first I thought of raising the issue here as something along the lines of "Broken -t and -w arguments," since that was the first problem I encountered. Upon running the commands without their optional arguments (-t,or -w) they function well, but while copying the tab id from the previous output of the command brave-cli list tabs and using the -t or -w options the command exits status 0 and the browser remains unchanged.

Testing chrome-cli with the same commands revealed it doesn't have the bug, and prior to yesterday afternoon brave-cli was working correctly with bugs on my os x, 10.15.xx "Catalina." Some quick brew queries revealed that I was using version 1.8.0 of chrome-cli, which I then updated to 1.9.1 which left the bug unchanged. It seems that I'm using version 1.51.110 of brave with cromium 113.0.5672.77

The matching ids are now abnormally high, well into the 14th power of 10, and I was wondering to myself "what the hell is going on?" Doing a little math seemed to peg the raise of each id by 2 million each time the I ran the cli.

Any help would be very much appreciated : )

[kkatayama]

I ran into a similar problem.

I use chrome-cli with google chrome. Yesterday my chrome auto updated from 112.0.5615.12 to 113.0.5672.63.

After the update, all requests for tab and window IDs responded with different values.

I ended up downgrading chrome back to 112.0.5615.12 and disabled automatic updates and now the tab and window IDs are back to being stable.

[prasmussen]

This is fixed in 1.9.3. Homebrew formula not updated yet (I'm to lazy to do it at the moment)

[prasmussen]

1.9.3 is now updated in homebrew