Feedback of shellFootGuns check doesn't seem to make its way to the LLM

[Hypfer]

I've found the LLM spinning for an hour, trying to execute a command and eventually believing that the dd binary must be broken.

Instead, I think what happened is that this must've triggered:

juggler/cmd/juggler/ops/shell_command_parse.go

Line 343 in 7d8a860

{regexp.MustCompile(`(?i)\bdd\s+if=`), "dd if="},

There is also this error message, apparently:

juggler/cmd/juggler/ops/shell_command_parse.go

Line 368 in 7d8a860

return fmt.Errorf("command contains dangerous pattern: %s", fg.reason)

But I'm not sure if it makes its way to the LLM, given that here:

juggler/web/extensions/juggler-core/context-items/execute-context-item.js

Lines 1009 to 1015 in 7d8a860

	_generateFeedbackForLLM(_command, _stdout, _stderr, exitCode) {
	// Only provide feedback for failed commands
	if (exitCode === 0) {
	return undefined;
	}
	return `Command failed with exit code ${exitCode}`;
	}

it only gets the exit code. Which is also what I see in the UI.

I have not yet told an LLM to trace through this, so this might be wrong, but what I can for sure say is:
"dd command failed, repeatedly, without feedback => LLM got very confused, scared and traumatized"

[julianstorer]

Thanks for reporting!

The server does emit the reason, and the streaming client keeps it. The caller then dropped it: the object returned at execute-context-item.js:907-916 lists command, stdout, stderr, exitCode, success and quietly discards error. So the model got (no output) / exit code: 1 and nothing to suggest retrying was pointless. The hour of confusion was ours, not the model's.

Fixed: error now travels with the result, and a refusal is additionally marked blocked — that terminal error field covers four situations (refused, bad cwd, failed to start, timed out) and only a refusal is futile to retry. A blocked command now says so, with the server's text verbatim. Same bug was losing command timeout (exceeded 20m0s) on timeouts, which nobody had noticed.

Your dd was also very probably innocent. The pattern was \bdd\s+if=, which matches any dd that reads anything, against the file's own rule that patterns stay narrow enough to miss everyday commands. Writing to a raw device was already caught by the adjacent pattern, so the dd if= entry is gone; of=/dev/sda is still blocked.

I've sorted this out on the develop branch, will be in the next release build!