Skip to content

Conversation

@Drilmo
Copy link
Contributor

@Drilmo Drilmo commented Jan 9, 2026

Summary

  • Add YOLO mode toggle button to enable/disable auto-approval of operations
  • Add YOLO mode indicator (⚡) in session list for sessions running in YOLO mode
  • Add inline session rename functionality - click on session title to edit

Bug Fixes

  • Fix messages not loading when reopening Agent Manager panel (pre-existing bug)
  • Fix race condition where pending session timeout could fire after provisional session was already created

Improvements

  • Add TypeScript types for respondToApproval and renameSession messages
  • Add translations for YOLO mode and rename features in all 21 supported locales

Screenshots

YOLO Mode Toggle

YOLO Mode Enabled YOLO Mode Disabled
YOLO mode enabled YOLO mode disabled

Session with YOLO Mode (Auto-approve)

No Approve/Deny buttons - operations are auto-approved:

YOLO mode session

Session without YOLO Mode (Manual approval)

Approve/Deny buttons visible for each operation:

Manual approval session

Approval Button States

Approved Denied Text Response (neither selected)
Approved Denied Text response

Inline Session Rename

Rename session

Test plan

  • Create a session with YOLO mode enabled and verify ⚡ indicator appears in session list
  • Create a session with YOLO mode disabled and verify no indicator appears
  • Click on session title to rename, verify it persists after panel close/reopen
  • Verify approval buttons (Approve/Deny) work correctly and persist state
  • Verify translations appear correctly in non-English locales

Add YOLO mode toggle button in session header to enable/disable
auto-approval of operations with indicator in session list.
Add inline session rename functionality.

Also fixes messages not loading when reopening panel and race
condition with pending session timeout.
@changeset-bot
Copy link

changeset-bot bot commented Jan 9, 2026

🦋 Changeset detected

Latest commit: f1184c8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
kilo-code Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@marius-kilocode marius-kilocode self-requested a review January 9, 2026 11:13
@marius-kilocode marius-kilocode requested review from kilocode-bot and marius-kilocode and removed request for marius-kilocode January 9, 2026 13:07
@marius-kilocode
Copy link
Collaborator

image

Thanks for the contribution. For me non-yolo mode still auto approves the commands (even though the buttons show).
I think the main problem is that there is a missing case handler in the AgentManagerProvider.ts to handle agentManager.respondToApproval

@Drilmo
Copy link
Contributor Author

Drilmo commented Jan 9, 2026

I think the main problem is that there is a missing case handler in the AgentManagerProvider.ts to handle agentManager.respondToApproval

@marius-kilocode Thanks for testing! The agentManager.respondToApproval handler is already implemented (line 278 of AgentManagerProvider.ts).

Could you check if you have a local CLI configuration that auto-approves echo? Try with a command that isn't auto-approved by default to confirm the approval flow works as expected.

@marius-kilocode
Copy link
Collaborator

marius-kilocode commented Jan 9, 2026

I dug a bit further. If i switch in an independent CLI to yolo mode the approval buttons don't work anymore. Once I switch back in a separate CLI to non-yolo the buttons work. I suspect this might either be a bug attached to:

//The code in question (cli.ts:287-295):
  // In JSON-IO mode, don't set yoloMode on the extension host.
  // This prevents Task.ts from auto-answering followup questions.
  // The CLI's approval layer handles YOLO behavior and correctly excludes followups.
  if (!this.options.jsonInteractive) {
      extensionHost.sendWebviewMessage({
          type: "yoloMode",
          bool: Boolean(this.options.ci || this.options.yolo),
      })
  }

which we might just remove now as we disabled the question tool in yolo mode on main. Or it is some global state architecture issue that somehow shares global yolo config state in between agent manager/cli sessions.

@Drilmo
Copy link
Contributor Author

Drilmo commented Jan 9, 2026

I investigated the echo auto-approve behavior. It's actually due to the default CLI config, not yoloMode:

// cli/src/config/defaults.ts
execute: {
    enabled: true,
    allowed: ["ls", "cat", "echo", "pwd"],
    denied: ["rm -rf", "sudo rm", "mkfs", "dd if="],
}

echo is in the default allowed list, so it auto-approves regardless of yoloMode. Try with a command not in this list (e.g., touch test.txt) to test the approval flow.

Still investigating the global state issue you mentioned separately.

@Drilmo
Copy link
Contributor Author

Drilmo commented Jan 9, 2026

@marius-kilocode Regarding your observation:

If i switch in an independent CLI to yolo mode the approval buttons don't work anymore. Once I switch back in a separate CLI to non-yolo the buttons work.

I'd like to understand better what's happening. Here's what I think the issue might be:

My understanding:
When you toggle YOLO mode in an independent CLI (via terminal), the Agent Manager session doesn't know about this change. There's no synchronization between the CLI's yoloMode and the Agent Manager's session state.

Proposed solution:
I've implemented bidirectional YOLO mode sync:

  • A toggle button (⚡) in Agent Manager session header to change yoloMode for running sessions
  • When toggled in Agent Manager → sends setYoloMode to CLI via stdin
  • When toggled in CLI → emits yoloModeChanged event back to Agent Manager

Questions:

  1. Is this the issue you're experiencing? Or is it something else?
  2. When you say "independent CLI", do you mean a CLI launched from VS Code terminal, or from the Kilo Code main panel, or something else?
  3. Can you describe step-by-step how to reproduce the issue?

I want to make sure I'm solving the right problem before pushing the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants