Yes, it was exactly the cursor shape when using Readline in vi mode.
This was my .inputrc file

$include /etc/inputrc

set editing-mode vi
$if mode=vi

set show-mode-in-prompt on
set vi-ins-mode-string \1\e[6 q\2
set vi-cmd-mode-string \1\e[2 q\2

set keymap vi-command
# these are for vi-command mode
Control-l: clear-screen
Control-a: beginning-of-line

set keymap vi-insert
# these are for vi-insert mode
Control-l: clear-screen
Control-a: beginning-of-line

$endif

and using the logic from
https://savannah.gnu.org/bugs/?49385
I turned it into

$include /etc/inputrc

set editing-mode vi
$if mode=vi

$if Octave
set show-mode-in-prompt off
$else
set show-mode-in-prompt on
set vi-ins-mode-string \1\e[6 q\2
set vi-cmd-mode-string \1\e[2 q\2

set keymap vi-command
# these are for vi-command mode
Control-l: clear-screen
Control-a: beginning-of-line

set keymap vi-insert
# these are for vi-insert mode
Control-l: clear-screen
Control-a: beginning-of-line
$endif

$endif

and now the octave prompt is alright.

Thank you very much!
(I would mark this topic as fixed, but I don't know how.)

Maybe something in an inputrc file that is setting it?

Somebody probably set octave's prompt to something too fancy.
What is PS1() value?
Or if you type at octave prompt PS1(">>")  does this junk go away?

Dmitri.
--

Does this display every time you press Enter to get a new prompt in the command window, or only once at startup?

The output you are seeing is not quite the same as bug #49385, compare

q>> undecodable token: \001b(hex)[6\0020(hex)

with

undecodable token: \001b(hex)[3m
undecodable token: \001b(hex)[23m

Your output is equivalent to "ESC [6 ". That seems like Octave or some program started by Octave is printing an invalid control sequence.