Desktop app ignores `askUser: false` from settings.json and offers no way to disable the ask_user tool

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

1. Set "askUser": false in ~/.copilot/settings.json.
2. Start copilot in a terminal and confirm the agent has no ask_user tool.
3. Open the desktop app against the same configuration directory and start any chat or project session.
4. 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

1. Is askUser intended to remain CLI-only, or should host-independent settings apply to every client that reads ~/.copilot?
2. Would defaultAgent.excludedTools be the preferred app-side mechanism, given the session wire already supports it?
3. 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.

Beginne in src-tauri/src/session/core.rs und untersuche, wie die Desktop-Session ihr Toolset und die SessionCreateWire-Felder erstellt. Vergleiche diesen Pfad mit der CLI-Behandlung von askUser in den untersuchten app.js-Belegen. Als erledigt gilt die Aufgabe, wenn die Anwendung askUser: false konsequent berücksichtigt oder eine gleichwertige Einstellung bereitstellt und dokumentiert und die resultierende Session verifiziert wurde, sodass sie ask_user ausschließt.