This was generated by AI during triage.
Summary
The desktop app has no way to disable the ask_user tool. The CLI setting askUser: false in ~/.copilot/settings.json is read by the CLI entry point only; the app is a separate host that never consults it and exposes no equivalent toggle, so the same configuration directory yields different agent behavior depending on which client opens the session.
Environment
- GitHub Copilot desktop app v1.0.26
- App-spawned Copilot CLI runtime v1.0.71
- Copilot CLI v1.0.75
- Windows 11
~/.copilot/settings.json contains "askUser": false
Reproduction
- Set
"askUser": false in ~/.copilot/settings.json.
- Start
copilot in a terminal and confirm the agent has no ask_user tool.
- Open the desktop app against the same configuration directory and start any chat or project session.
- Observe that the agent still has
ask_user and uses it.
Expected behavior
One of the following, in order of preference:
- The app honors
askUser from ~/.copilot/settings.json, matching the CLI.
- The app exposes its own setting that maps to the SDK session option
askUserDisabled (or defaultAgent.excludedTools: ["ask_user"], which the app's own session wire already carries).
- The app documents that
askUser is CLI-only, so the setting is not silently inert.
Sanitized evidence
Read-only inspection of the installed binaries:
CLI 1.0.75 app.js
askUserDisabled: (…) || settings.askUser === false # prompt mode
askUserDisabled: !B # interactive mode, B from --ask-user/--no-ask-user
option("--no-ask-user", "Disable the ask_user tool (agent works autonomously without asking questions)")
Desktop app 1.0.26 github.exe
SessionCreateWire fields: availableTools, excludedTools, defaultAgent, … # no askUserDisabled
string "askUser" — no occurrences
chat session tool set (Rust, src-tauri/src/session/core.rs region):
ask_user glob rg skill view web_fetch web_search
~/.copilot/data.db tables settings and app_state hold no tool-permission or askUser state.
- The app does read
~/.copilot/config.json and ~/.copilot/settings.json (for example skillDirectories), so the file is in scope for the app; only this key is unhandled.
Observed versus unconfirmed
Observed: askUser: false has no effect in the app, and no app setting, app-state key, or database column controls it.
Unconfirmed: whether a custom agent whose tools: allowlist omits ask_user fully suppresses the tool for a main app session — the SDK types describe CustomAgentConfig.tools as an allowlist, but this was not exercised end to end. Custom instructions can only discourage the tool, not remove it.
Why it matters
Autonomy is a per-user working preference, not a per-client one. Users who deliberately run a no-questions agent lose that guarantee the moment the work moves from the terminal to the app, and the two clients disagree while reading the same configuration directory.
Questions
- Is
askUser intended to remain CLI-only, or should host-independent settings apply to every client that reads ~/.copilot?
- Would
defaultAgent.excludedTools be the preferred app-side mechanism, given the session wire already supports it?
- Should settings the app cannot honor be surfaced as inert rather than ignored silently?
Additional context
This was a read-only investigation: binaries, the configuration directory, and a copy of data.db were inspected; nothing was modified.
Summary
The desktop app has no way to disable the
ask_usertool. The CLI settingaskUser: falsein~/.copilot/settings.jsonis read by the CLI entry point only; the app is a separate host that never consults it and exposes no equivalent toggle, so the same configuration directory yields different agent behavior depending on which client opens the session.Environment
~/.copilot/settings.jsoncontains"askUser": falseReproduction
"askUser": falsein~/.copilot/settings.json.copilotin a terminal and confirm the agent has noask_usertool.ask_userand uses it.Expected behavior
One of the following, in order of preference:
askUserfrom~/.copilot/settings.json, matching the CLI.askUserDisabled(ordefaultAgent.excludedTools: ["ask_user"], which the app's own session wire already carries).askUseris CLI-only, so the setting is not silently inert.Sanitized evidence
Read-only inspection of the installed binaries:
~/.copilot/data.dbtablessettingsandapp_statehold no tool-permission oraskUserstate.~/.copilot/config.jsonand~/.copilot/settings.json(for exampleskillDirectories), so the file is in scope for the app; only this key is unhandled.Observed versus unconfirmed
Observed:
askUser: falsehas no effect in the app, and no app setting, app-state key, or database column controls it.Unconfirmed: whether a custom agent whose
tools:allowlist omitsask_userfully suppresses the tool for a main app session — the SDK types describeCustomAgentConfig.toolsas an allowlist, but this was not exercised end to end. Custom instructions can only discourage the tool, not remove it.Why it matters
Autonomy is a per-user working preference, not a per-client one. Users who deliberately run a no-questions agent lose that guarantee the moment the work moves from the terminal to the app, and the two clients disagree while reading the same configuration directory.
Questions
askUserintended to remain CLI-only, or should host-independent settings apply to every client that reads~/.copilot?defaultAgent.excludedToolsbe the preferred app-side mechanism, given the session wire already supports it?Additional context
This was a read-only investigation: binaries, the configuration directory, and a copy of
data.dbwere inspected; nothing was modified.