support kiloCode & first commit#1466
Conversation
|
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
|
||
| loop { | ||
| let batch = agent.read_incremental(&path, current_watermark, &session.session_id)?; | ||
| let batch = agent.read_incremental(&path, current_watermark, &session.external_session_id)?; |
There was a problem hiding this comment.
🚩 transcript_worker session_id→external_session_id change fixes pre-existing OpenCode bug
The change at line 500 from session.session_id to session.external_session_id is a behavioral change for ALL agents, not just Kilo. For SQLite-based agents (OpenCode, Kilo), read_incremental uses the session_id parameter to query WHERE session_id = ? against the external tool's database. The external database stores original session IDs, not git-ai generated hashes. Before this PR, OpenCode's transcript reading was likely broken (querying with a hash that would never match). For file-based agents (Claude, Cursor, etc.), this parameter is only used in error messages, so the change is harmless. This is effectively a bug fix with a broad blast radius that happens to also enable Kilo.
Was this helpful? React with 👍 or 👎 to provide feedback.
| fn lookup_parent_session(db_path: &Path, session_id: &str) -> Option<String> { | ||
| let conn = crate::transcripts::agents::opencode::open_sqlite_readonly(db_path).ok()?; | ||
| conn.query_row( | ||
| "SELECT parent_id FROM session WHERE id = ?", | ||
| [session_id], | ||
| |row| row.get::<_, Option<String>>(0), | ||
| ) | ||
| .ok() | ||
| .flatten() | ||
| } |
There was a problem hiding this comment.
🚩 Kilo preset reuses OpenCode's SQLite schema assumptions
The Kilo preset's lookup_parent_session (src/commands/checkpoint_agent/presets/kilo.rs:172-181) queries SELECT parent_id FROM session WHERE id = ?, and extract_model_from_opencode_sqlite (src/transcripts/model_extraction.rs:231-276) queries a message table with specific column layouts. Both assume Kilo Code's SQLite database has the same schema as OpenCode's (session table with id/parent_id, message table with session_id/data columns containing modelID fields). If Kilo Code's actual schema differs, these queries will silently return None due to .ok()? and .ok().flatten() error handling — model extraction and parent session lookup would fail silently, defaulting to "unknown" model. This is graceful degradation but worth confirming the schema matches.
Was this helpful? React with 👍 or 👎 to provide feedback.
| fn plugin_path() -> PathBuf { | ||
| home_dir() | ||
| .join(".config") | ||
| .join("kilo") | ||
| .join("plugins") | ||
| .join("git-ai.ts") | ||
| } |
There was a problem hiding this comment.
📝 Info: Kilo plugin and installer use different base directories on Linux (config vs data)
The hook installer at src/mdm/agents/kilo.rs:27-32 uses XDG_CONFIG_HOME (defaulting to ~/.config/kilo/plugins/) for the plugin file, while the transcript/preset code at src/commands/checkpoint_agent/presets/kilo.rs:196-204 and src/transcripts/agents/kilo.rs:178-188 use XDG_DATA_HOME (defaulting to ~/.local/share/kilo/) for the database path. This is intentional — plugins are config, databases are data — following XDG Base Directory conventions. Confirmed this matches Kilo Code's actual directory structure expectations.
Was this helpful? React with 👍 or 👎 to provide feedback.
| fn kilocode_data_path() -> Result<PathBuf, GitAiError> { | ||
| #[cfg(target_os = "macos")] | ||
| { | ||
| let home = dirs::home_dir().ok_or_else(|| { | ||
| GitAiError::Generic("Could not determine home directory".to_string()) | ||
| })?; | ||
| Ok(home.join(".local").join("share").join("kilo")) | ||
| } | ||
|
|
||
| #[cfg(target_os = "linux")] | ||
| { | ||
| if let Ok(xdg_data) = std::env::var("XDG_DATA_HOME") { | ||
| Ok(PathBuf::from(xdg_data).join("kilo")) | ||
| } else { | ||
| let home = dirs::home_dir().ok_or_else(|| { | ||
| GitAiError::Generic("Could not determine home directory".to_string()) | ||
| })?; | ||
| Ok(home | ||
| .join("Library") | ||
| .join("Application Support") | ||
| .join("kilo")) | ||
| } | ||
| } | ||
|
|
||
| #[cfg(target_os = "windows")] | ||
| { | ||
| if let Ok(app_data) = std::env::var("APPDATA") { | ||
| Ok(PathBuf::from(app_data).join("kilo")) | ||
| } else if let Ok(local_app_data) = std::env::var("LOCALAPPDATA") { | ||
| Ok(PathBuf::from(local_app_data).join("kilo")) | ||
| } else { | ||
| Err(GitAiError::Generic( | ||
| "Neither APPDATA nor LOCALAPPDATA is set".to_string(), | ||
| )) | ||
| } | ||
| } | ||
|
|
||
| #[cfg(not(any(target_os = "macos", target_os = "linux", target_os = "windows")))] | ||
| { | ||
| Err(GitAiError::PresetError( | ||
| "Kilo Code storage path not supported on this platform".to_string(), | ||
| )) | ||
| } | ||
| } |
There was a problem hiding this comment.
🚩 Three separate kilocode_data_path() implementations with inconsistent logic
There are three separate implementations of the Kilo data path resolution: KiloPreset::kilocode_data_path() at src/commands/checkpoint_agent/presets/kilo.rs:183, KiloAgent::kilocode_data_path() at src/transcripts/agents/kilo.rs:164, and KiloInstaller::plugin_path() at src/mdm/agents/kilo.rs:15. Beyond the swapped-paths bug already reported, the preset uses dirs::home_dir() while the agent uses std::env::var("HOME"), which can behave differently in edge cases. Additionally, on macOS the agent uses Library/Application Support/kilo while the installer uses Library/Application Support/kilo/plugins/ (correct parent). Having three separate implementations of what is essentially the same platform-specific path logic increases the risk of future inconsistencies. Consider extracting a shared utility.
Was this helpful? React with 👍 or 👎 to provide feedback.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
2 participants
I have been using kilocode git ai recently and there is no relevant support provided
I have developed a contribution to the community
I have passed the test
Thank you