Skip to content

Conversation

@iceweasel-oai
Copy link
Collaborator

We will disable input while the elevated sandbox setup is running.

Copy link
Contributor

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8dcea2833f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines 495 to +498
pub fn handle_key_event(&mut self, key_event: KeyEvent) -> (InputResult, bool) {
if !self.input_enabled {
return (InputResult::None, false);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Block paste events when input is disabled

The new input_enabled gate only short-circuits handle_key_event, but paste events still go through BottomPane::handle_pasteChatComposer::handle_paste without checking input_enabled, so a bracketed paste (or clipboard paste event) will still insert text or attach images while the UI is in a read-only state. This makes the “input disabled” state inconsistent and can mutate the composer during sandbox setup; consider guarding paste handling on the same flag.

Useful? React with 👍 / 👎.

Comment on lines 412 to +415
pub fn handle_key_event(&mut self, key_event: KeyEvent) -> (InputResult, bool) {
if !self.input_enabled {
return (InputResult::None, false);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Block paste events when input is disabled

As in the original TUI, input_enabled only affects handle_key_event, but paste events still flow through handle_paste without checking the flag, so clipboard pastes can still change the text or add attachments even though input is supposed to be blocked. This breaks the read-only expectation during sandbox setup; consider gating paste handling on input_enabled as well.

Useful? React with 👍 / 👎.

Copy link
Collaborator

@dylan-hurd-oai dylan-hurd-oai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 comment, but otherwise LGTM

"›".bold()
} else {
"›".dim()
};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[non-blocking] I wonder if this is visually distinguished enough

@iceweasel-oai iceweasel-oai merged commit ccba737 into main Jan 8, 2026
26 checks passed
@iceweasel-oai iceweasel-oai deleted the dev/iceweasel/tui-input-enabled-2 branch January 8, 2026 04:56
@github-actions github-actions bot locked and limited conversation to collaborators Jan 8, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants