feat(request-help): add BSK_REQUEST_HELP=off to disable blocking help requests - #53
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
bsk request-helpis a blocking human-in-the-loop command: it brings the tab to the foreground, shows the help overlay, and waits until the user acts or the call times out (default 5m). On unattended / background-server deployments there is no human around, and a blocking help prompt must never appear — but today there is no way to turn the command off.What changes
New environment variable
BSK_REQUEST_HELP:BSK_REQUEST_HELP=off(case-insensitive, surrounding whitespace ignored) disablesrequest-help.When disabled,
bsk request-helpreturns immediately — no daemon startup, no overlay, no waiting — with a synthetic structured result and exit code 0:{ "outcome": "disabled", "note": "request-help disabled by BSK_REQUEST_HELP=off (unattended mode)", "tab_id": 0 }The agent therefore gets a normal, machine-readable result instead of an error and can react deliberately (the skill docs now tell agents not to retry
request-helpafter adisabledoutcome, and to continue autonomously or stop gracefully).Implementation
bsk-protocol: newHelpOutcome::Disabledvariant ("disabled") + regeneratedtool_request_help_result.jsonschema.human_loop.rs):dispatch()short-circuits beforeensure_daemon()when disabled; theoffvalue parsing lives in a pure, unit-tested helper.ipc.rs):handle_tool_dispatchrefuses to forwardtool.request_helpto the extension when disabled and answers with the same synthetic result, so non-CLI IPC callers are covered too.transport/types.ts:HelpOutcomeunion gains"disabled"(no behaviour change — the daemon never forwards the call when disabled).skill/SKILL.mdcopies document the variable's purpose (unattended mode), its exact behaviour, and the agent guidance above.Tests
cargo fmt --all,cargo clippy -p bsk-protocol -p bsk --all-targets -- -D warnings: clean.cargo test -p bsk-protocol: 104 passed.cargo test -p bsk: all green except one pre-existing, environment-dependent failure inskill_install::sync::tests::sync_continues_on_partial_error(also fails on a clean tree in this environment; unrelated to this change).offvalue detection anddisabledoutcome serialization.