Three things a live session against testenv on 2026-08-16 turned up. None is a crash; each is a place where the tool tells somebody something that is not quite so.
1. An upload reports a version that does not appear
rbx place upload --env ops --file place.rbxl answered:
main (99887766555) ... v1
Upload complete.
and rbx place versions still lists one version, dated two weeks earlier, under every filter — all, saved and published alike. So either Roblox does not create a version for byte-identical content and the command reports the existing number as if it were new, or the response is being read wrongly.
The next step is cheap and was not done for want of time: change one byte of the file and upload again. If a new version appears, the tool is reporting a no-op as a write, which is the more interesting of the two answers.
2. config sync --yes still stops on a prompt
$ rbx config sync --env ops --yes
Changes:
+ validation.flag = true
Error: Prompt error: IO error: not a terminal
--yes skips the confirmation, and then resolve_message asks for a publish message with no non-interactive path of its own. --no-message is the second flag needed, and nothing says so: --yes reads as "do not ask me anything".
This is a CI failure mode. A pipeline running config sync --yes does not hang — it fails on a prompt it cannot answer — but the message it fails with names a terminal rather than the flag that fixes it.
Either --yes should imply an empty message, or the error should name --message / --no-message. The first is what a reader expects from the flag's name.
3. --filter published on a place with no published version says "0 found"
Correct, and worth a word in the output. A place that has only draft versions answers (no versions) under the default filter's sibling, which reads as "this place has nothing" rather than "nothing is published yet". One line naming the other filter would close it.
Re-filed from #114 when the repository history was reset for 0.1.0. Issue and PR numbers referenced above belong to the previous numbering and no longer resolve; the reasoning does not depend on them.
Three things a live session against
testenvon 2026-08-16 turned up. None is a crash; each is a place where the tool tells somebody something that is not quite so.1. An upload reports a version that does not appear
rbx place upload --env ops --file place.rbxlanswered:and
rbx place versionsstill lists one version, dated two weeks earlier, under every filter —all,savedandpublishedalike. So either Roblox does not create a version for byte-identical content and the command reports the existing number as if it were new, or the response is being read wrongly.The next step is cheap and was not done for want of time: change one byte of the file and upload again. If a new version appears, the tool is reporting a no-op as a write, which is the more interesting of the two answers.
2.
config sync --yesstill stops on a prompt--yesskips the confirmation, and thenresolve_messageasks for a publish message with no non-interactive path of its own.--no-messageis the second flag needed, and nothing says so:--yesreads as "do not ask me anything".This is a CI failure mode. A pipeline running
config sync --yesdoes not hang — it fails on a prompt it cannot answer — but the message it fails with names a terminal rather than the flag that fixes it.Either
--yesshould imply an empty message, or the error should name--message/--no-message. The first is what a reader expects from the flag's name.3.
--filter publishedon a place with no published version says "0 found"Correct, and worth a word in the output. A place that has only draft versions answers
(no versions)under the default filter's sibling, which reads as "this place has nothing" rather than "nothing is published yet". One line naming the other filter would close it.Re-filed from #114 when the repository history was reset for 0.1.0. Issue and PR numbers referenced above belong to the previous numbering and no longer resolve; the reasoning does not depend on them.