InputBoxTypeSetting 'universal' from cloud sync corrupts terminal on Linux+Fish

[hernanharco]

Summary

Setting input_box_type_setting gets overwritten by cloud sync with the legacy value "universal" even when is_settings_sync_enabled = false (bug #6692). This causes [ERROR] Failed to parse file value for setting InputBoxTypeSetting followed by Inhibiting writes for setting key terminal.input.input_box_type_setting. After this, every command becomes corrupted: the agent setup script concatenates with the user command WITHOUT a separator.

Steps to reproduce

1. Have a Warp Cloud account with input_box_type_setting = "universal" stored (legacy value from old versions)
2. Set is_settings_sync_enabled = false in settings.toml
3. Restart Warp on Linux with fish shell
4. Observe: settings.toml keeps getting overwritten with is_settings_sync_enabled = true and input_box_type_setting = "universal"
5. Every command fails with:

source '/tmp/.tmpXXXXX'cd /some/path
source: Error encountered while sourcing file '/tmp/.tmpXXXXXcd':
source: No existe el archivo o el directorio

Actual behavior

• input_box_type_setting gets overwritten by cloud sync despite is_settings_sync_enabled = false (related to AI setting is synced even when Settings sync is diabled #6692)
• Logs show: [ERROR] Failed to parse file value for setting InputBoxTypeSetting and Inhibiting writes for setting key terminal.input.input_box_type_setting
• The agent setup script concatenates with the user command without a separator (missing ; or newline)
• Terminal becomes completely unusable — every command is corrupted
• Banner error: "Invalid value for 'input_box_type_setting'"

Expected behavior

• is_settings_sync_enabled = false should completely disable cloud sync for ALL settings (fix for AI setting is synced even when Settings sync is diabled #6692)
• When a setting value is invalid, Warp should fall back gracefully without corrupting input
• Agent setup scripts should be properly separated from user commands (similar to PR Harden interactive shell PATH capture against rc startup output #12473 fix)

Environment

• OS: Linux (Ubuntu 24.04)
• Warp version: v0.2026.07.01.09.21.stable_01
• Shell: fish (via Homebrew)
• Window system: X11
• Installation: deb package

Key logs

[ERROR] Failed to parse file value for setting InputBoxTypeSetting
[INFO] Inhibiting writes for setting key terminal.input.input_box_type_setting
[INFO] Updating local preference with storage key InputBoxTypeSetting and value "universal" to match cloud preference
[WARN] Error Failed to parse value for InputBoxTypeSetting comparing local value "Editor" for cloud preference

Related

• AI setting is synced even when Settings sync is diabled #6692 — AI setting syncs even when Settings sync is disabled (OPEN)
• Fish not working #5444 — Fish not working (OPEN)
• PR Harden interactive shell PATH capture against rc startup output #12473 — Fixed similar concatenation bug for PATH capture (MERGED)

[oz-for-oss]

@hernanharco

Here's what I found while triaging this issue:

• The logs support that Warp is applying a cloud-stored setting even after the local sync toggle is set to false; the sync toggle itself can be restored from cloud.
• This does not look like a straight duplicate of AI setting is synced even when Settings sync is diabled #6692 or Fish not working #5444 because it adds a Fish command-concatenation failure that makes commands unusable.

Maintainer details

I concluded that cloud-synced input-box preferences can appear to re-enable settings sync and, in the reported Linux/Fish setup, lead to Fish bootstrap/input command concatenation that makes commands unusable..

Triage summary

This looks like a real bug involving two interacting paths:

• Cloud preference reconciliation can restore account.is_settings_sync_enabled from cloud even when the local settings file has it set to false, because the sync-enabled preference itself is registered to sync regardless of the user's sync preference. Once that cloud value is restored, cloud-stored public settings such as InputBoxTypeSetting can be applied locally.
• The reported command corruption is specific enough to route to the Linux/Fish terminal bootstrap/input path. Fish local sessions use an RC-file bootstrap method that writes source '<tmpfile>' and then terminates it separately; the observed source '/tmp/...'cd ... output suggests a queued user/agent command can be appended before the bootstrap source command is fully separated.

Current main appears to parse the snake_case file value "universal" for InputBoxTypeSetting, so the invalid-value banner may be version-specific to the reporter's stable build or tied to the exact cloud/native value shape stored for the account. The cloud-sync overwrite behavior is still supported by the current code structure, especially because IsSettingsSyncEnabled uses RespectUserSyncSetting::No.

Duplicate search did not meet the threshold for marking this as a duplicate. #6692 overlaps the settings-sync-disabled behavior, #5444 overlaps Fish startup/shell problems, and #6842 overlaps cloud preferences overwriting local preferences, but none cover the same legacy input-box setting plus Fish command concatenation failure.

Suggested next owner focus: settings/cloud preferences for the sync toggle and legacy value migration, with terminal input/Fish bootstrap support for the command concatenation symptom.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz