* ## ✅ Implementation Complete!
I've successfully implemented the warning system for Claude Code when `apiKeySource` is not "/login managed key". Here's what was implemented:
### **Changes Made:**
1. **Added `api_key_source` field to `ClaudeJson::System`**
- Added `#[serde(default, rename = "apiKeySource")] api_key_source: Option<String>` field
- Backward-compatible with existing JSON parsing
2. **Created warning helper function**
- `warn_if_unmanaged_key()` function that generates warning entries when API key source is not managed
- Includes both UI warning and server-side `tracing::warn!()` logging
3. **Modified system message processing**
- Updated `normalize_entries()` to check API key source and emit warnings immediately
- Warning appears for any `apiKeySource` value except "/login managed key" and `None`
4. **Added comprehensive test coverage**
- Test for warning generation with unmanaged keys
- Test for no warning with managed keys
- Test for no warning when field is missing
- All existing tests pass
### **Warning Message:**
```
⚠️ Using apiKeySource "ANTHROPIC_API_KEY" – calls will be billed to that key. Run `claude-code login` (or set `/login managed key`) if you want to route usage through the managed key.
```
### **Key Features:**
- **Immediate visibility**: Warning shows up immediately in the UI as a normalized system message
- **Server-side logging**: Also logs to server with `tracing::warn!()`
- **Backward compatible**: No breaking changes, works with existing implementations
- **Comprehensive**: Handles all cases (managed, unmanaged, missing field)
- **Actionable**: Provides clear guidance on how to fix the issue
The implementation is ready for production use!
* Cleanup script changes for task attempt 4345b766-b8ed-4949-aefb-32e20e891a01
* ## ✅ Review Feedback Addressed!
I've successfully updated the implementation based on your review comments:
### **Changes Made:**
1. **Updated warning logic (Line 621)**
- Changed from checking "not `/login managed key`" to specifically checking for `"ANTHROPIC_API_KEY"`
- Now only warns when `apiKeySource` equals exactly `"ANTHROPIC_API_KEY"`
- All other values (including `/login managed key`, missing field, or other keys) do not trigger warnings
2. **Updated warning message (Line 631)**
- Changed from the generic billing warning to the specific message:
- **New message:** `"ANTHROPIC_API_KEY env variable detected, your Anthropic subscription is not being used"`
3. **Updated tests to reflect new behavior**
- Tests now verify warning only appears for `"ANTHROPIC_API_KEY"`
- Tests confirm no warning for managed keys, other keys, or missing field
- Validates exact warning message content
### **Final Behavior:**
- ✅ **Warning shown**: When `apiKeySource` = `"ANTHROPIC_API_KEY"`
- ✅ **No warning**: When `apiKeySource` = `"/login managed key"`
- ✅ **No warning**: When `apiKeySource` = any other value
- ✅ **No warning**: When `apiKeySource` field is missing
The implementation now specifically targets the `ANTHROPIC_API_KEY` environment variable scenario and provides a clear, focused warning message about Anthropic subscription usage.
* Cleanup script changes for task attempt 4345b766-b8ed-4949-aefb-32e20e891a01
* ## ✅ Warning Triangle Added!
I've successfully added the warning triangle (⚠️) to the warning message as requested.
### **Final Warning Message:**
```
⚠️ ANTHROPIC_API_KEY env variable detected, your Anthropic subscription is not being used
```
### **Changes Made:**
- **Line 628**: Added `⚠️` to the warning message content
- **Updated test**: Modified the test assertion to expect the warning triangle in the message
The warning now has a clear visual indicator (⚠️) that makes it more noticeable to users when the `ANTHROPIC_API_KEY` environment variable is being used instead of their Anthropic subscription through Claude Code.
The implementation is complete and ready for production use!
1. **Removed the ROUTER profile** from `/crates/executors/default_profiles.json` (lines 14-19)
2. **Verified the changes** with cargo clippy - no warnings or errors
3. **Confirmed frontend compatibility** - linting passed with only existing warnings (no errors)
The ROUTER profile variant that enabled `claude_code_router: true` is no longer available in the default profiles. Users will no longer see "ROUTER" as a profile option for CLAUDE_CODE, but existing users with this configuration will still work due to the migration logic that remains in place.
* rework process start card
* do not auto-insert user message
* error and system message cards
* nest tool cards
* improve tool card rendering
* fix tsc errors
* spacing
* scroll bar
* tweaks
* put back icon
* use run reason constants
* fix restore icon display
* round diff card
* add special plan card rendering
* fmt
* opacity for thinking text
* Louis/logs tweaks (#641)
* remove divs
* text
* status indicator
* expandable tool boxes
* diffs and raw logs
* Tweaks
* new files
* message
* lint
---------
Co-authored-by: Louis Knight-Webb <louis@bloop.ai>
* ## 🎉 Implementation Complete!
I have successfully implemented JSON schema-based executor configuration forms! Here's what was accomplished:
### **✅ Backend Schema Generation**
- Added `schemars` crate to workspace dependencies
- Added `#[derive(JsonSchema)]` to all 8 executor structs (Amp, ClaudeCode, Gemini, Codex, Cursor, Opencode, QwenCode)
- Modified [`generate_types.rs`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-4b73-use-the-sc/crates/server/src/bin/generate_types.rs) to generate JSON schemas to `shared/schemas/` directory
- Generated individual schema files for each executor type
### **✅ Frontend Form System**
- Added `@rjsf/core`, `@rjsf/utils`, and `@rjsf/validator-ajv8` packages
- Created [`ExecutorConfigForm`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-4b73-use-the-sc/frontend/src/components/ExecutorConfigForm.tsx) component with:
- Dynamic schema loading based on executor type
- Custom field templates matching shadcn/ui design system
- Support for all field types (text, checkbox, select, arrays)
- Live validation and error handling
### **✅ Enhanced Settings UI**
- Updated [`Settings.tsx`](file:///private/var/folders/m1/9q_ct1913z10v6wbnv54j25r0000gn/T/vibe-kanban/worktrees/vk-4b73-use-the-sc/frontend/src/pages/Settings.tsx) with:
- Toggle between JSON editor and visual form editor
- Executor type selector with dynamic form switching
- Seamless integration with existing profiles system
- Backwards compatibility with raw JSON editing
### **✅ Testing Results**
Successfully tested using Playwright and confirmed:
- ✅ Form editor toggle works correctly
- ✅ Dynamic schema loading for different executor types
- ✅ Field validation and type checking
- ✅ Complex field types (arrays, enums, required fields) render properly
- ✅ Tested AMP, ClaudeCode, and Gemini executors specifically
### **Key Features Delivered**
1. **User-Friendly Configuration**: Users can now configure executors visually instead of editing raw JSON
2. **Type Safety**: Generated schemas ensure configuration validity
3. **Dynamic Forms**: Each executor type shows only relevant fields
4. **Backwards Compatibility**: Users can still switch back to JSON mode
5. **Professional UI**: Custom templates match the existing design system
6. **Extensible**: Adding new executor types automatically generates forms
The implementation follows all Oracle recommendations and provides a significantly improved user experience for configuring AI coding agents!
* Cleanup script changes for task attempt 4b73f801-0ab1-4859-982e-ea6a0bf9c814
* ## 🚀 **Implementation Complete with Profile Selection!**
Your question was perfectly answered! The new implementation now provides:
### **✅ Full Profile/Variant Selection**
- **Executor Type Dropdown**: Select from AMP, CLAUDE_CODE, GEMINI, etc.
- **Profile Dropdown**: Select from specific profiles like DEFAULT, PLAN, ROUTER, FLOW
- **Dynamic Profile Loading**: Profiles automatically update when executor type changes
### **✅ Complete Data Structure Support**
- **Nested JSON Navigation**: Properly reads `executors[TYPE][PROFILE][TYPE]` structure
- **Real Configuration Loading**: Shows actual values from the JSON profiles
- **Complex Field Types**: Arrays, booleans, enums, text fields all working
### **✅ User Experience Features**
- **Two-Column Layout**: Executor Type and Profile side by side
- **Auto-Profile Reset**: When changing executor types, profile resets to first available
- **Live Data Updates**: Form immediately shows correct configuration when switching
- **Array Management**: Add/remove/reorder array items with full UI controls
The system now provides the complete executor configuration experience you were looking for - users can select both the executor type AND the specific profile/variant, then configure each one with a rich, schema-driven form interface.
* Cleanup script changes for task attempt 4b73f801-0ab1-4859-982e-ea6a0bf9c814
* improvements
* append_prompt
* generate forms
* order
* settings
* amp MCP config update
* form styles
* textarea
* style additional params
* validate
* menu styles
* prevent reload
* fmt
* add and delete configurations
* lint
* fmnt
* clippy
* prettier
* copy
* remove old MCP
* Auto detect schemas on FE
* wipe shared before generation
* fmt
* clippy fmt
* fixes
* fmt
* update shared types check
* disable clippy for large enum
* copy
* tweaks
* fmt
* fmt
* feat: add availability check for coding agents and set smart defaults for new users
* Add executor discovery (vibe-kanban d65d61aa)
Plan: Add executor discovery with appropriate checks
Understanding
You're absolutely right! Checking if npx is available is useless for Opencode/Qwen since it doesn't tell us if those specific agents have been set up. We should follow the pattern used by other executors:
Binary-based executors (like Cursor): Check if the binary exists
NPX-based executors (like Claude, Gemini, Opencode, Qwen): Check for their settings files
Implementation Plan
1. Cursor executor (cursor.rs, after line 407)
Since Cursor uses a standalone binary:
async fn check_availability(&self) -> bool {
utils::shell::resolve_executable_path("cursor-agent").is_some()
}
Import needed: Add shell::resolve_executable_path to the utils import
2. Opencode executor (opencode.rs, after line 188)
Follow the pattern of other NPX-based executors - check for settings file:
async fn check_availability(&self) -> bool {
self.default_mcp_config_path()
.map(|path| path.exists())
.unwrap_or(false)
}
This will check for the opencode.json file in the appropriate location (XDG on Unix, config_dir on Windows).
3. QwenCode executor (qwen.rs, after line 140)
Same approach as other NPX-based executors:
async fn check_availability(&self) -> bool {
self.default_mcp_config_path()
.map(|path| path.exists())
.unwrap_or(false)
}
This will check for ~/.qwen/settings.json.
Why this approach is correct:
Cursor: Has a specific binary that must be installed → check for binary
Opencode/Qwen: Are NPX-based like Claude/Gemini → check for settings files
Consistency: Follows the existing pattern where NPX-based executors check for settings files
Meaningful detection: Settings files indicate the agent has been configured/used before, which is what we want for "availability"
This gives us meaningful availability detection that matches the existing patterns in the codebase.
* Remove duplicated config paths (vibe-kanban 207e0410)
In some executors, like crates/executors/src/executors/amp.rs , Paths for checking availability and mcp server are identical but not reused. We should not duplicate code. Consider changing the default availability check to just check for the mcp config
* feat: implement recommended executor profile retrieval for new users
* fmt
* Make variants an object rather than array (vibe-kanban 63213864)
Profile variants should be an object, with key used instead of the current label.
The code should be refactored leaving no legacy trace.
crates/server/src/routes/config.rs
crates/executors/src/profile.rs
* Make variants an object rather than array (vibe-kanban 63213864)
Profile variants should be an object, with key used instead of the current label.
The code should be refactored leaving no legacy trace.
crates/server/src/routes/config.rs
crates/executors/src/profile.rs
* Remove the command builder from profiles (vibe-kanban d30abc92)
It should no longer be possible to customise the command builder in profiles.json.
Instead, anywhere where the command is customised, the code should be hardcoded as an enum field on the executor, eg claude code vs claude code router on the claude code struct.
crates/executors/src/profile.rs
crates/executors/src/executors/claude.rs
* fmt
* Refactor Qwen log normalization (vibe-kanban 076fdb3f)
Qwen basically uses the same log normalization as Gemini, can you refactor the code to make it more reusable.
A similar example exists in Amp, where we use Claude's log normalization.
crates/executors/src/executors/amp.rs
crates/executors/src/executors/qwen.rs
crates/executors/src/executors/claude.rs
* Add field overrides to executors (vibe-kanban cc3323a4)
We should add optional fields 'base_command_override' (String) and 'additional_params' (Vec<String>) to each executor, and wire these fields up to the command builder
* Update profiles (vibe-kanban e7545ab6)
Redesign the profile configuration storage system to store only differences from defaults instead of complete profile files. Implement partial profile functions (create_partial_profile, load_from_partials, save_as_diffs) that save human-readable partial profiles containing only changed values. Update ProfileConfigs::load() to handle the new partial format while maintaining backward compatibility with legacy full profile formats through automatic migration that creates backups. Implement smart variants handling that only stores changed, added, or removed variants rather than entire arrays. Fix the profile API consistency issue by replacing the manual file loading logic in the get_profiles() endpoint in crates/server/src/routes/config.rs with ProfileConfigs::get_cached() to ensure the GET endpoint uses the same cached data that PUT updates. Add comprehensive test coverage for all new functionality.
* Yolo mode becomes a field (vibe-kanban d8dd02f0)
Most executors implement some variation of yolo-mode, can you make this boolean field on each executor (if supported), where the name for the field aligns with the CLI field
* Change ClaudeCodeVariant to boolean (vibe-kanban cc05956f)
Instead of an enum ClaudeCodeVariant, let's use a variable claude_code_router to determine whether to use claude_code_router's command. If the user has also supplied a base_command_override this should take precedence (also write a warning to console)
crates/executors/src/executors/claude.rs
* Remove mcp_config_path from profile config (vibe-kanban 6c1e5947)
crates/executors/src/profile.rs
* One profile per executor (vibe-kanban b0adc27e)
Currently you can define arbitrary profiles, multiple profiles per executor. Let's refactor to simplify this configuration, instead we should only be able to configure one profile per executor.
The new format should be something like:
```json
{
"profiles": {
"CLAUDE_CODE": {
"default": {
"plan": false,
"dangerously_skip_permissions": true,
"append_prompt": null
},
"plan": {
"plan": true,
"dangerously_skip_permissions": false,
"append_prompt": null
}
}
}
}
```
Each profile's defaults should be defined as code instead of in default_profiles.json
profile.json will now contain:
- Overrides for default configurations
- Additional user defined configurations, for executors
It is not possible to remove a default configuration entirely, just override the configuration.
The user profile.json should still be a minimal set of overrides, to make upgrading easy.
Don't worry about migration, this will be done manually.
crates/executors/default_profiles.json
crates/executors/src/profile.rs
* SCREAMING_SNAKE_CASE
* update profile.rs
* config migration
* fmt
* delete binding
* config keys
* fmt
* shared types
* Profile variants should be saved as SCREAMING_SNAKE_CASE (vibe-kanban 5c6c124c)
crates/executors/src/profile.rs save_overrides
* rename default profiles
* remove defaulted executor fields
* backwards compatability
* fix legacy variants
* ## ✅ Implementation Complete!
I've successfully implemented the duplicate task feature. Here's what was accomplished:
### **Changes Made:**
1. **TaskDialogContext (`frontend/src/contexts/task-dialog-context.tsx`)**
- Added `initialTask: Task | null` to dialog state
- Created `openDuplicate(task, options)` method that opens create dialog with initial data
- Updated all existing methods to include initialTask field
2. **TaskFormDialog (`frontend/src/components/tasks/TaskFormDialog.tsx`)**
- Added `initialTask?: Task | null` prop
- Enhanced prefill logic with priority: Edit → Duplicate → Template → Empty
- Duplicated tasks reset status to 'todo' and start with no images
3. **TaskCard (`frontend/src/components/tasks/TaskCard.tsx`)**
- Added Copy icon import
- Added `onDuplicate?: (task: Task) => void` prop
- Added "Duplicate" menu item with Copy icon between Edit and Delete
4. **TaskKanbanBoard (`frontend/src/components/tasks/TaskKanbanBoard.tsx`)**
- Added `onDuplicateTask?: (task: Task) => void` prop
- Passed duplicate handler through to TaskCard components
5. **ProjectTasks (`frontend/src/pages/project-tasks.tsx`)**
- Added `openDuplicate` to useTaskDialog destructuring
- Created `handleDuplicateTask` function
- Passed duplicate handler to TaskKanbanBoard
6. **TaskFormDialogContainer (`frontend/src/components/tasks/TaskFormDialogContainer.tsx`)**
- Added `initialTask={dialogState.initialTask}` prop to TaskFormDialog
### **How It Works:**
1. **User clicks** the "⋯" menu on any task card
2. **Sees "Duplicate"** option with copy icon between Edit and Delete
3. **Clicks Duplicate** → opens create task dialog with:
- Title and description pre-filled from original task
- Status reset to 'todo'
- No images (clean slate)
- User can modify and create as normal
### **Key Design Decisions:**
- **Treated as create mode** (not edit) - follows Oracle's recommendation
- **Status always resets to 'todo'** for duplicated tasks
- **No images copied** - simple and safe approach
- **Clean integration** with existing template system
The implementation passes all TypeScript checks and follows the existing codebase patterns. The feature is ready to use!
* Cleanup script changes for task attempt 16b21999-278c-414d-aaab-ae5767d42d77
