Issue Station
Sign In
Tools hereToolbox

gemini-cli - ✅(Solved) Fix setShellExecutionConfig() drops sandbox/background shell config fields [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
google-gemini/gemini-cli#25112•Fetched 2026-04-11 06:31:28
View on GitHub
Comments
0
Participants
1
Timeline
10
Reactions
0
Author
jasonmatthewsuharijasonmatthewsuhari
Participants
jasonmatthewsuharijasonmatthewsuhari
Timeline (top)
labeled ×3cross-referenced ×2added_to_project_v2 ×1closed ×1

Root Cause

The interactive app calls config.setShellExecutionConfig(...) during normal UI operation, so this is not just an internal inconsistency. It means runtime shell behavior can drift away from the config established during startup.

Fix Action

Fixed

PR fix notes

PR #25113: fix(core): preserve shell execution config fields on update

Description (problem / solution / changelog)

Fixes #25112

Summary

  • preserve existing ShellExecutionConfig fields when updating interactive shell dimensions
  • add a regression test covering sandboxConfig and backgroundCompletionBehavior

Why

Config.setShellExecutionConfig() was rebuilding the object from a stale subset of fields. In current main, the interactive UI updates shell dimensions during normal operation, so this could silently drop runtime shell fields like sandboxConfig and backgroundCompletionBehavior after startup.

Testing

  • npm run test --workspace @google/gemini-cli-core -- src/config/config.test.ts

Changed files

  • packages/core/src/config/config.test.ts (modified, +47/-0)
  • packages/core/src/config/config.ts (modified, +1/-0)

PR #25130: fix(core): preserve shell execution config fields

Description (problem / solution / changelog)

Fixes #25112

Summary

Preserve existing shell execution config fields when the UI refreshes layout-related values, so sandbox and background-completion settings are not dropped at runtime.

Validation

  • npm test packages/core/src/config/config.test.ts

Changed files

  • packages/cli/src/ui/hooks/useSessionResume.ts (modified, +3/-0)
  • packages/core/src/config/config.test.ts (modified, +37/-0)
  • packages/core/src/config/config.ts (modified, +21/-0)

Code Example

before {"sandboxConfig":{"enabled":true,"allowedPaths":[],"includeDirectories":["C:\\Users\\Jason\\.gemini\\tmp"],"networkAccess":false,"command":"windows-native"},"backgroundCompletionBehavior":"notify","terminalWidth":80,"terminalHeight":24}
after {"terminalWidth":123,"terminalHeight":45}
RAW_BUFFERClick to expand / collapse

What happened

While exercising current main, I found that updating shell UI dimensions through config.setShellExecutionConfig(...) removes existing shellExecutionConfig fields already present on the Config instance.

I reproduced this against built origin/main code in a clean worktree (5fc8fea8d762d67d3bff14d00307138faff0bca5) by instantiating Config with:

  • sandbox.enabled = true
  • sandbox.command = "windows-native"
  • sandbox.networkAccess = false
  • shellBackgroundCompletionBehavior = "notify"

Then I called config.setShellExecutionConfig(...) with only the fields the interactive UI currently sets (terminalWidth, terminalHeight, pager, showColor, sanitizationConfig, sandboxManager).

Observed output:

before {"sandboxConfig":{"enabled":true,"allowedPaths":[],"includeDirectories":["C:\\Users\\Jason\\.gemini\\tmp"],"networkAccess":false,"command":"windows-native"},"backgroundCompletionBehavior":"notify","terminalWidth":80,"terminalHeight":24}
after {"terminalWidth":123,"terminalHeight":45}

Expected

Calling setShellExecutionConfig(...) to update layout-related fields should preserve existing fields that are still part of ShellExecutionConfig, especially behavior/security-related ones such as:

  • sandboxConfig
  • backgroundCompletionBehavior

Actual

Those fields are dropped from the config object after setShellExecutionConfig(...) runs.

Why this matters

The interactive app calls config.setShellExecutionConfig(...) during normal UI operation, so this is not just an internal inconsistency. It means runtime shell behavior can drift away from the config established during startup.

Likely area

  • packages/core/src/config/config.ts
  • Config.setShellExecutionConfig()
  • packages/cli/src/ui/AppContainer.tsx

extent analysis

TL;DR

Update the Config.setShellExecutionConfig() method to merge new fields with existing ones instead of replacing the entire shellExecutionConfig object.

Guidance

  • Review the Config.setShellExecutionConfig() method in packages/core/src/config/config.ts to ensure it handles partial updates correctly.
  • Verify that the method is not inadvertently creating a new shellExecutionConfig object, causing existing fields to be lost.
  • Check the packages/cli/src/ui/AppContainer.tsx file to see if it's passing only the updated fields to setShellExecutionConfig(), which might be contributing to the issue.
  • Consider adding a test case to ensure that setShellExecutionConfig() preserves existing fields when updating only some of them.

Example

// Example of how setShellExecutionConfig might be updated to merge new fields
setShellExecutionConfig(newConfig: Partial<ShellExecutionConfig>) {
  this.shellExecutionConfig = { ...this.shellExecutionConfig, ...newConfig };
}

Notes

The exact implementation of the fix will depend on the specifics of the Config class and the setShellExecutionConfig() method, which are not fully detailed in the issue.

Recommendation

Apply a workaround by modifying the Config.setShellExecutionConfig() method to correctly handle partial updates, as this will directly address the observed issue and prevent runtime shell behavior from drifting away from the initial config.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#cache error#pipeline error#runtime error#dependency conflict#environment setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

gemini-cli - ✅(Solved) Fix setShellExecutionConfig() drops sandbox/background shell config fields [2 pull requests, 1 participants]