-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
fix(ACS-175): Resolve integrations freeze and improve rate limit handling #839
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
fix(ACS-175): Resolve integrations freeze and improve rate limit handling #839
Conversation
📝 WalkthroughWalkthroughAdds debug logging to CLAUDE profile initialization and terminal resume flows, switches Claude CLI invocation to a resolved absolute command, implements chunked PTY writes for large payloads, and replaces blocking alert dialogs with localized non-blocking toasts across multiple renderer components. Changes
Sequence Diagram(s)sequenceDiagram
participant Renderer
participant Main
participant PTY as PTY/Terminal
participant ClaudeCLI as Claude CLI
Renderer->>Main: CLAUDE_PROFILE_INITIALIZE(profileId)
Main->>Main: debug logs, lookup profile, ensure config dir
Main->>PTY: create terminal for auth
PTY-->>Main: terminal created (id)
Main->>PTY: wait for terminal ready
Main->>Main: resolve Claude CLI path, build loginCommand (OS-specific)
Main->>PTY: write loginCommand (chunked if large)
PTY->>ClaudeCLI: command input via terminal
Main->>Renderer: notify terminal-created(profileId, terminalId)
Renderer->>Renderer: show localized toast (authenticating)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello @MikeeBuilds, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the user experience by addressing UI freezing issues during Claude profile integration and improving how rate limit modals are handled. It achieves this by implementing a chunked writing mechanism for terminal processes to prevent UI blocking, replacing intrusive Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request successfully resolves a UI freeze issue by implementing a chunked writing mechanism for large data payloads and improves the user experience by replacing blocking alert() dialogs with non-blocking toast notifications. The changes are well-targeted. However, a significant amount of debugging console.log statements have been introduced across multiple files, which must be removed before merging. Additionally, there are opportunities to improve error handling consistency and code clarity in the new PTY writing logic.
| ipcMain.handle( | ||
| IPC_CHANNELS.CLAUDE_PROFILE_INITIALIZE, | ||
| async (_, profileId: string): Promise<IPCResult> => { | ||
| console.log('[IPC:CLAUDE_PROFILE_INITIALIZE] Handler called for profileId:', profileId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A large number of console.log and console.error statements have been added throughout this file for debugging (e.g., here and on lines 317, 319, 322, 325, 341, 350, 352, 363, 365, 369, 372, 396, 397, 401, 403, 407, 417, 426). These should be removed before merging to keep production logs clean. If some logging is desired, please use the existing debugLog and debugError utilities.
| */ | ||
| export function writeToPty(terminal: TerminalProcess, data: string): void { | ||
| terminal.pty.write(data); | ||
| console.log('[PtyManager:writeToPty] About to write to pty, data length:', data.length); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function contains many console.log and console.error statements for debugging. Please remove them all before merging to avoid polluting production logs. If logging is necessary, consider using a dedicated, level-based logger like debugLog and debugError which are used elsewhere in the codebase.
| console.error('[PtyManager:writeToPty] Write FAILED:', error); | ||
| throw error; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error handling here is inconsistent with the chunked write logic. While the chunked path catches and logs errors, this path re-throws the error. Since the caller (TerminalManager.write) doesn't handle exceptions, this could lead to an uncaught exception. For consistency and stability, you should log the error here using debugError instead of re-throwing it. This will require importing debugError from ../../shared/utils/debug-logger.
} catch (error) {
console.error('[PtyManager:writeToPty] Write FAILED:', error);
}| * Send input to a terminal | ||
| */ | ||
| write(id: string, data: string): void { | ||
| console.log('[TerminalManager:write] Writing to terminal:', id, 'data length:', data.length); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| }; | ||
|
|
||
| const handleAuthenticateProfile = async (profileId: string) => { | ||
| console.log('[IntegrationSettings] handleAuthenticateProfile called for:', profileId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| if (data.length > 1000) { | ||
| console.log('[PtyManager:writeToPty] Large write detected, using chunked write'); | ||
| const chunkSize = 100; // Smaller chunks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 8
🤖 Fix all issues with AI agents
In @apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx:
- Line 30: OAuthStep currently logs toast messages with hardcoded English
strings; import and call useTranslation (e.g., const { t } =
useTranslation('settings')) at the top of the OAuthStep component and replace
every hardcoded toast message in functions that call useToast (locations around
the Toast calls currently at OAuth success, auth start failed, add profile
failed, auth failed, token saved success, token save failed and the token save
catch) with the appropriate translation keys from settings.json (use
t('namespace.key') or t('oauth.success') style keys matching the entries added
in settings.json) while keeping the existing useToast invocation and payload
structure unchanged so only the message/title fields use t(...) instead of
literal strings.
In @apps/frontend/src/renderer/components/RateLimitModal.tsx:
- Around line 136-140: The toast call in RateLimitModal (the toast invocation
with variant: 'destructive', title: 'Failed to add profile', description:
'Please try again.') uses hardcoded strings; replace them with i18n translation
keys following the pattern used in IntegrationSettings.tsx (use the project's
translation hook/utility and keys like
integrationSettings.addProfileFailed.title and .description or similar),
ensuring you call the translation function inside RateLimitModal and pass the
translated strings to toast instead of literal text.
In @apps/frontend/src/renderer/components/SDKRateLimitModal.tsx:
- Around line 180-184: The toast call in SDKRateLimitModal uses hardcoded
English strings; replace them with i18n translation keys by using the existing
translation hook (e.g., the component's useTranslation/useI18n -> t) and call
toast({ variant: 'destructive', title:
t('sdkRateLimitModal.addProfileFailed.title'), description:
t('sdkRateLimitModal.addProfileFailed.description') }); add corresponding keys
to the locale JSON files following the project's naming convention
(sdkRateLimitModal.addProfileFailed.title and .description) and ensure the
translation hook is imported/initialized in the SDKRateLimitModal component if
not already.
- Around line 165-175: The toast calls in SDKRateLimitModal.tsx use hardcoded
English strings; import and call the i18n hook (useTranslation) in the
component, replace the literal titles/descriptions with translation keys (e.g.,
t('sdk.authenticating', { profileName }) and t('sdk.check_terminal') for the
success toast, and t('sdk.auth_failed') with either initResult.error or
t('sdk.try_again') for the error toast), and ensure profileName and
initResult.error are passed into the translation/interpolation where needed.
In @apps/frontend/src/renderer/components/settings/IntegrationSettings.tsx:
- Line 215: Replace the ad-hoc console.log calls in handleAuthenticateProfile
with the project's debug logging utility: remove the console.log statements
(including the ones at lines shown) and call debugLog(...) instead, importing
debugLog from the same utility module used elsewhere; ensure each message
preserves its context (e.g., include profileId and relevant state) and matches
existing debugLog usage patterns in other components so logs are consistent and
can be toggled in production.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (9)
apps/frontend/src/main/ipc-handlers/terminal-handlers.tsapps/frontend/src/main/terminal/pty-manager.tsapps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/renderer/components/RateLimitModal.tsxapps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/renderer/components/settings/IntegrationSettings.tsxapps/frontend/src/shared/i18n/locales/en/settings.jsonapps/frontend/src/shared/i18n/locales/fr/settings.json
🧰 Additional context used
📓 Path-based instructions (4)
apps/frontend/src/**/*.{ts,tsx,jsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings
Files:
apps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/main/terminal/pty-manager.tsapps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/main/ipc-handlers/terminal-handlers.tsapps/frontend/src/renderer/components/RateLimitModal.tsxapps/frontend/src/renderer/components/settings/IntegrationSettings.tsx
apps/frontend/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Use
useTranslation()hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components
Files:
apps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/main/terminal/pty-manager.tsapps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/main/ipc-handlers/terminal-handlers.tsapps/frontend/src/renderer/components/RateLimitModal.tsxapps/frontend/src/renderer/components/settings/IntegrationSettings.tsx
apps/frontend/**/*.{ts,tsx}
⚙️ CodeRabbit configuration file
apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.
Files:
apps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/main/terminal/pty-manager.tsapps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/main/ipc-handlers/terminal-handlers.tsapps/frontend/src/renderer/components/RateLimitModal.tsxapps/frontend/src/renderer/components/settings/IntegrationSettings.tsx
apps/frontend/src/shared/i18n/locales/**/*.json
📄 CodeRabbit inference engine (CLAUDE.md)
apps/frontend/src/shared/i18n/locales/**/*.json: Store translation strings in namespace-organized JSON files atapps/frontend/src/shared/i18n/locales/{lang}/*.jsonfor each supported language
When implementing new frontend features, add translation keys to all language files (minimum: en/.json and fr/.json)
Files:
apps/frontend/src/shared/i18n/locales/en/settings.jsonapps/frontend/src/shared/i18n/locales/fr/settings.json
🧠 Learnings (3)
📚 Learning: 2026-01-04T23:59:45.209Z
Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:45.209Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings) can be deferred for future i18n cleanup passes. Do not fix such issues in PRs that do not introduce new i18n violations, especially in frontend TSX components (e.g., apps/frontend/**/*.tsx). If a PR adds new i18n violations, address them in that PR.
Applied to files:
apps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/renderer/components/RateLimitModal.tsxapps/frontend/src/renderer/components/settings/IntegrationSettings.tsx
📚 Learning: 2025-12-30T16:38:36.314Z
Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/frontend/src/shared/i18n/locales/**/*.json : When implementing new frontend features, add translation keys to all language files (minimum: en/*.json and fr/*.json)
Applied to files:
apps/frontend/src/shared/i18n/locales/en/settings.jsonapps/frontend/src/shared/i18n/locales/fr/settings.json
📚 Learning: 2026-01-04T12:37:52.222Z
Learnt from: StillKnotKnown
Repo: AndyMik90/Auto-Claude PR: 648
File: apps/frontend/src/renderer/components/settings/ModelSearchableSelect.tsx:262-265
Timestamp: 2026-01-04T12:37:52.222Z
Learning: Dropdown components in apps/frontend/src/renderer/components/settings use a fixed max-height (e.g., max-h-60) with internal overflow-y-auto scrolling. This pattern is intentional and prevents dropdowns from extending beyond the viewport; do not add dynamic viewport positioning or clipping-prevention logic for these components. If you add new dropdowns in this area, follow the same fixed-height + internal-scroll approach for consistency.
Applied to files:
apps/frontend/src/renderer/components/settings/IntegrationSettings.tsx
🧬 Code graph analysis (5)
apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx (1)
apps/frontend/src/renderer/hooks/use-toast.ts (2)
useToast(192-192)toast(192-192)
apps/frontend/src/main/terminal/pty-manager.ts (1)
apps/frontend/src/main/terminal/types.ts (1)
TerminalProcess(8-22)
apps/frontend/src/main/ipc-handlers/terminal-handlers.ts (3)
apps/frontend/src/main/claude-profile-manager.ts (1)
getClaudeProfileManager(560-565)apps/frontend/src/main/claude-cli-utils.ts (1)
getClaudeCliInvocationAsync(66-77)apps/frontend/src/shared/utils/shell-escape.ts (1)
escapeShellArg(24-29)
apps/frontend/src/renderer/components/RateLimitModal.tsx (1)
apps/frontend/src/renderer/hooks/use-toast.ts (2)
useToast(192-192)toast(192-192)
apps/frontend/src/renderer/components/settings/IntegrationSettings.tsx (1)
apps/frontend/src/renderer/hooks/use-toast.ts (2)
useToast(192-192)toast(192-192)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: CodeQL (python)
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (8)
apps/frontend/src/main/terminal/terminal-manager.ts (1)
123-131: LGTM! Diagnostic logging aids troubleshooting.The added logging provides visibility into terminal write operations, which aligns with the PR's goal of resolving integration freeze issues. The logs track data length, terminal existence, and operation completion.
apps/frontend/src/shared/i18n/locales/en/settings.json (1)
440-451: LGTM! Translation keys properly added.The new toast notification keys are well-structured and provide clear user-facing messages for authentication, profile management, and token handling scenarios.
Note: Ensure these translation keys are referenced in UI components rather than hardcoded strings (see OAuthStep.tsx review).
apps/frontend/src/shared/i18n/locales/fr/settings.json (1)
440-451: LGTM! French translations properly added.The toast keys mirror the English locale structure, maintaining consistency across languages as required by the coding guidelines.
Based on learnings, both en/.json and fr/.json must be updated for new features.
apps/frontend/src/renderer/components/RateLimitModal.tsx (1)
25-25: LGTM!The useToast hook is correctly imported and initialized.
Also applies to: 33-33
apps/frontend/src/renderer/components/SDKRateLimitModal.tsx (1)
24-24: LGTM!The useToast hook is correctly imported and initialized.
Also applies to: 59-59
apps/frontend/src/renderer/components/settings/IntegrationSettings.tsx (2)
32-32: LGTM!The useToast hook is correctly imported and initialized.
Also applies to: 47-47
88-92: Excellent i18n usage in toast notifications!The toast notifications correctly use translation keys via the
t()function, and the useEffect dependencies properly include bothtandtoast. This is the correct pattern that should be followed throughout the codebase.Also applies to: 97-97
apps/frontend/src/main/ipc-handlers/terminal-handlers.ts (1)
368-394: LGTM - Secure command construction with proper shell escaping.The command construction has been refactored to use the full Claude CLI path directly, with proper shell escaping for both Windows and POSIX systems. This approach is more secure than PATH manipulation and correctly handles:
- Windows cmd.exe syntax with
escapeShellArgWindows- Unix/Mac bash/zsh syntax with
escapeShellArg- Environment variable setting for non-default profiles
- Simple command for default profiles
| export function writeToPty(terminal: TerminalProcess, data: string): void { | ||
| terminal.pty.write(data); | ||
| console.log('[PtyManager:writeToPty] About to write to pty, data length:', data.length); | ||
|
|
||
| // For large commands, write in chunks to prevent blocking | ||
| if (data.length > 1000) { | ||
| console.log('[PtyManager:writeToPty] Large write detected, using chunked write'); | ||
| const chunkSize = 100; // Smaller chunks | ||
| let offset = 0; | ||
| let chunkNum = 0; | ||
|
|
||
| const writeChunk = () => { | ||
| if (offset >= data.length) { | ||
| console.log('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum); | ||
| return; | ||
| } | ||
|
|
||
| const chunk = data.slice(offset, offset + chunkSize); | ||
| chunkNum++; | ||
| console.log('[PtyManager:writeToPty] Writing chunk', chunkNum, 'offset:', offset, 'size:', chunk.length); | ||
| try { | ||
| terminal.pty.write(chunk); | ||
| console.log('[PtyManager:writeToPty] Chunk', chunkNum, 'written'); | ||
| offset += chunkSize; | ||
| // Use setImmediate to yield to the event loop between chunks | ||
| setImmediate(writeChunk); | ||
| } catch (error) { | ||
| console.error('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error); | ||
| } | ||
| }; | ||
|
|
||
| // Start the chunked write after yielding | ||
| console.log('[PtyManager:writeToPty] Scheduling first chunk...'); | ||
| setImmediate(writeChunk); | ||
| console.log('[PtyManager:writeToPty] First chunk scheduled, returning'); | ||
| } else { | ||
| try { | ||
| terminal.pty.write(data); | ||
| console.log('[PtyManager:writeToPty] Write completed successfully'); | ||
| } catch (error) { | ||
| console.error('[PtyManager:writeToPty] Write FAILED:', error); | ||
| throw error; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Critical: Asynchronous chunked write with no completion tracking.
The function returns immediately for large writes while chunks continue writing asynchronously via setImmediate. This creates several issues:
- No completion notification – Callers cannot determine when the write finishes.
- Error handling gap – Errors in later chunks (line 184) are logged but not propagated to the caller since the function has already returned.
- Race condition risk – The terminal PTY could be killed or the
TerminalProcessobject destroyed while chunks are still queued. - Very small chunks – 100-byte chunks for data >1000 bytes could queue hundreds of callbacks for large payloads.
Recommended fixes
Option 1: Return a Promise so callers can await completion:
-export function writeToPty(terminal: TerminalProcess, data: string): void {
+export function writeToPty(terminal: TerminalProcess, data: string): Promise<void> {
console.log('[PtyManager:writeToPty] About to write to pty, data length:', data.length);
// For large commands, write in chunks to prevent blocking
if (data.length > 1000) {
console.log('[PtyManager:writeToPty] Large write detected, using chunked write');
- const chunkSize = 100; // Smaller chunks
+ const chunkSize = 1000; // Larger chunks to reduce overhead
let offset = 0;
let chunkNum = 0;
- const writeChunk = () => {
+ return new Promise<void>((resolve, reject) => {
+ const writeChunk = () => {
- if (offset >= data.length) {
- console.log('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum);
- return;
- }
+ if (offset >= data.length) {
+ console.log('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum);
+ resolve();
+ return;
+ }
- const chunk = data.slice(offset, offset + chunkSize);
- chunkNum++;
- console.log('[PtyManager:writeToPty] Writing chunk', chunkNum, 'offset:', offset, 'size:', chunk.length);
- try {
- terminal.pty.write(chunk);
- console.log('[PtyManager:writeToPty] Chunk', chunkNum, 'written');
- offset += chunkSize;
- // Use setImmediate to yield to the event loop between chunks
- setImmediate(writeChunk);
- } catch (error) {
- console.error('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error);
- }
- };
+ const chunk = data.slice(offset, offset + chunkSize);
+ chunkNum++;
+ console.log('[PtyManager:writeToPty] Writing chunk', chunkNum, 'offset:', offset, 'size:', chunk.length);
+ try {
+ terminal.pty.write(chunk);
+ console.log('[PtyManager:writeToPty] Chunk', chunkNum, 'written');
+ offset += chunkSize;
+ setImmediate(writeChunk);
+ } catch (error) {
+ console.error('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error);
+ reject(error);
+ }
+ };
- // Start the chunked write after yielding
- console.log('[PtyManager:writeToPty] Scheduling first chunk...');
- setImmediate(writeChunk);
- console.log('[PtyManager:writeToPty] First chunk scheduled, returning');
+ console.log('[PtyManager:writeToPty] Scheduling first chunk...');
+ setImmediate(writeChunk);
+ });
} else {
try {
terminal.pty.write(data);
console.log('[PtyManager:writeToPty] Write completed successfully');
+ return Promise.resolve();
} catch (error) {
console.error('[PtyManager:writeToPty] Write FAILED:', error);
- throw error;
+ return Promise.reject(error);
}
}
}Then update the caller in terminal-manager.ts:
- write(id: string, data: string): void {
+ async write(id: string, data: string): Promise<void> {
console.log('[TerminalManager:write] Writing to terminal:', id, 'data length:', data.length);
const terminal = this.terminals.get(id);
if (terminal) {
console.log('[TerminalManager:write] Terminal found, calling writeToPty...');
- PtyManager.writeToPty(terminal, data);
+ await PtyManager.writeToPty(terminal, data);
console.log('[TerminalManager:write] writeToPty completed');
} else {
console.error('[TerminalManager:write] Terminal NOT found:', id);
}
}Option 2: If you cannot change the signature, at least track pending writes and handle terminal destruction:
+// Track pending writes per terminal
+const pendingWrites = new Map<string, number>();
+
export function writeToPty(terminal: TerminalProcess, data: string): void {
console.log('[PtyManager:writeToPty] About to write to pty, data length:', data.length);
if (data.length > 1000) {
+ const terminalId = terminal.id;
+ pendingWrites.set(terminalId, (pendingWrites.get(terminalId) || 0) + 1);
+
const writeChunk = () => {
+ // Check if terminal still exists
+ if (!terminal.pty) {
+ console.warn('[PtyManager:writeToPty] Terminal destroyed, aborting chunked write');
+ pendingWrites.set(terminalId, Math.max(0, (pendingWrites.get(terminalId) || 1) - 1));
+ return;
+ }
+
if (offset >= data.length) {
console.log('[PtyManager:writeToPty] Chunked write completed');
+ pendingWrites.set(terminalId, Math.max(0, (pendingWrites.get(terminalId) || 1) - 1));
return;
}
// ... rest of chunk logic
};
}
}Committable suggestion skipped: line range outside the PR's diff.
apps/frontend/src/renderer/components/settings/IntegrationSettings.tsx
Outdated
Show resolved
Hide resolved
Addresses CodeRabbit review feedback on PR AndyMik90#839: - OAuthStep.tsx: use t() for all toast messages - RateLimitModal.tsx: use t() for toast messages - SDKRateLimitModal.tsx: add useTranslation hook, use t() for toasts - Add toast translation keys to en/fr onboarding.json and common.json
|
@coderabbitai @gemini-code-assist I've addressed the i18n feedback:
Please re-review when convenient! 🙏 |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 4257 @MikeeBuilds Perfect! I've verified all your i18n changes and they look excellent! ✅ Verification Results: ✅ OAuthStep.tsx: All toast calls now use Your implementation correctly uses the proper namespace prefixes and includes complete translations in both English and French. The i18n feedback has been fully addressed! 🎉 🧠 Learnings used |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request effectively resolves UI freezes by replacing blocking alert dialogs with non-blocking toast notifications and optimizing terminal data writing. The introduction of chunked writing in pty-manager.ts is a great performance improvement for handling large data outputs. The consistent use of toast notifications across different components improves the user experience significantly.
My main feedback is regarding the numerous console.log and console.error statements added for debugging purposes. While useful during development, they should be removed before merging to keep the production console clean. I've left comments on the relevant files to point these out.
| console.log('[PtyManager:writeToPty] About to write to pty, data length:', data.length); | ||
|
|
||
| // For large commands, write in chunks to prevent blocking | ||
| if (data.length > 1000) { | ||
| console.log('[PtyManager:writeToPty] Large write detected, using chunked write'); | ||
| const chunkSize = 100; // Smaller chunks | ||
| let offset = 0; | ||
| let chunkNum = 0; | ||
|
|
||
| const writeChunk = () => { | ||
| if (offset >= data.length) { | ||
| console.log('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum); | ||
| return; | ||
| } | ||
|
|
||
| const chunk = data.slice(offset, offset + chunkSize); | ||
| chunkNum++; | ||
| console.log('[PtyManager:writeToPty] Writing chunk', chunkNum, 'offset:', offset, 'size:', chunk.length); | ||
| try { | ||
| terminal.pty.write(chunk); | ||
| console.log('[PtyManager:writeToPty] Chunk', chunkNum, 'written'); | ||
| offset += chunkSize; | ||
| // Use setImmediate to yield to the event loop between chunks | ||
| setImmediate(writeChunk); | ||
| } catch (error) { | ||
| console.error('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error); | ||
| } | ||
| }; | ||
|
|
||
| // Start the chunked write after yielding | ||
| console.log('[PtyManager:writeToPty] Scheduling first chunk...'); | ||
| setImmediate(writeChunk); | ||
| console.log('[PtyManager:writeToPty] First chunk scheduled, returning'); | ||
| } else { | ||
| try { | ||
| terminal.pty.write(data); | ||
| console.log('[PtyManager:writeToPty] Write completed successfully'); | ||
| } catch (error) { | ||
| console.error('[PtyManager:writeToPty] Write FAILED:', error); | ||
| throw error; | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| console.log('[TerminalManager:write] Writing to terminal:', id, 'data length:', data.length); | ||
| const terminal = this.terminals.get(id); | ||
| if (terminal) { | ||
| console.log('[TerminalManager:write] Terminal found, calling writeToPty...'); | ||
| PtyManager.writeToPty(terminal, data); | ||
| console.log('[TerminalManager:write] writeToPty completed'); | ||
| } else { | ||
| console.error('[TerminalManager:write] Terminal NOT found:', id); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| console.log('[IntegrationSettings] handleAuthenticateProfile called for:', profileId); | ||
| setAuthenticatingProfileId(profileId); | ||
| try { | ||
| console.log('[IntegrationSettings] Calling initializeClaudeProfile IPC...'); | ||
| const initResult = await window.electronAPI.initializeClaudeProfile(profileId); | ||
| console.log('[IntegrationSettings] IPC returned:', initResult); | ||
| if (!initResult.success) { | ||
| alert(`Failed to start authentication: ${initResult.error || 'Please try again.'}`); | ||
| toast({ | ||
| variant: 'destructive', | ||
| title: t('integrations.toast.authStartFailed'), | ||
| description: initResult.error || t('integrations.toast.tryAgain'), | ||
| }); | ||
| } | ||
| // Note: If successful, the terminal is now visible in the UI via the onTerminalAuthCreated event | ||
| // Users can see the 'claude setup-token' output and complete OAuth flow directly | ||
| } catch (err) { | ||
| console.error('Failed to authenticate profile:', err); | ||
| alert('Failed to start authentication. Please try again.'); | ||
| console.error('[IntegrationSettings] Failed to authenticate profile:', err); | ||
| toast({ | ||
| variant: 'destructive', | ||
| title: t('integrations.toast.authStartFailed'), | ||
| description: t('integrations.toast.tryAgain'), | ||
| }); | ||
| } finally { | ||
| console.log('[IntegrationSettings] finally block - clearing authenticatingProfileId'); | ||
| setAuthenticatingProfileId(null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addresses CodeRabbit review feedback - use project's debug logging utility for consistent and toggle-able logging in production.
|
@coderabbitai @gemini-code-assist @AndyMik90 Pushed an additional fix for the
All CodeRabbit review items should now be addressed. Ready for re-review! 🙏 |
|
Hello @MikeeBuilds, thank you for the update! I've noted the additional fix for replacing This is a good improvement for consistent and controlled logging within the application. I'll proceed with a re-review of the updated changes. 🙏 |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 940 @MikeeBuilds Excellent work! I've verified all your Verification Results: ✅ debugLog import added: Line 33 shows Your implementation is clean and follows the project's logging standards. All review feedback has been fully addressed! 🎉 🧠 Learnings usedIf you found this review helpful, would you consider giving us a shout-out on X? Thank you for using CodeRabbit! |
| let offset = 0; | ||
| let chunkNum = 0; | ||
|
|
||
| const writeChunk = () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔥
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MikeeBuilds @AndyMik90 I think we are good on this for a while, but we may want to think ahead to see what something like Tauri would look like for a Cloud version. Much better multi-threading with Rust that would allow us to avoid some of these blocking scenarios.
aslaker
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤖 Auto Claude PR Review
Merge Verdict: 🟠 NEEDS REVISION
🟠 Needs revision - 9 issue(s) require attention.
9 issue(s) must be addressed (5 required, 4 recommended), 1 suggestions
Risk Assessment
| Factor | Level | Notes |
|---|---|---|
| Complexity | Medium | Based on lines changed |
| Security Impact | None | Based on security findings |
| Scope Coherence | Good | Based on structural review |
Findings Summary
- High: 5 issue(s)
- Medium: 4 issue(s)
- Low: 1 issue(s)
Generated by Auto Claude PR Review
Findings (10 selected of 10 total)
🟠 [5e70bef47e08] [HIGH] Console.log statements not replaced with debugLog as claimed
📁 apps/frontend/src/main/ipc-handlers/terminal-handlers.ts:315
The PR description claims 'Replaced console.log with debugLog' but this handler contains 14+ console.log statements (lines 315, 317, 319, 322, 325, 341, 350, 352, 363, 365, 369, 372, 396, 397, 401, 403, 407, 417). This same file already imports and uses debugLog elsewhere (lines 10, 187-286, 332, 342, 398), showing the pattern is established but not followed in the new code.
Suggested fix:
Replace all console.log statements with debugLog, and console.error with debugError. The imports already exist in this file.
🟠 [246d2cf4bf39] [HIGH] Verbose console.log statements in writeToPty function
📁 apps/frontend/src/main/terminal/pty-manager.ts:159
The writeToPty function contains 10 console.log/console.error statements that log on every PTY write operation. This will generate excessive log output during normal operation. The codebase pattern for main process files is to use debugLog from the shared debug-logger utility.
Suggested fix:
Import debugLog from '../../shared/utils/debug-logger' and replace console.log statements. For console.error, use debugError.
🟡 [a806f5211b8d] [MEDIUM] Console.log statements in write method
📁 apps/frontend/src/main/terminal/terminal-manager.ts:123
The write method contains 4 console.log/console.error statements that log on every terminal write operation. Should use debugLog for consistency with codebase patterns.
Suggested fix:
Replace console.log on lines 123, 126, 128 with debugLog. The console.error on line 130 could stay or use debugError.
🟠 [e26db54eba18] [HIGH] Hardcoded UI strings violate i18n guidelines
📁 apps/frontend/src/renderer/components/SDKRateLimitModal.tsx:247
This component has numerous hardcoded English strings instead of using i18n translation keys. Examples: 'Claude Code Rate Limit' (line 247), 'Upgrade to Pro for Higher Limits', 'Select account...', 'Switch Account & Retry', 'Retrying...', 'Retry', 'Close'. The sibling RateLimitModal.tsx correctly uses t('rateLimit.modalTitle') patterns.
Suggested fix:
Replace all hardcoded strings with translation keys using t() function. Add corresponding keys to en/common.json and fr/common.json under the rateLimit section.
🟠 [706370be0a87] [HIGH] Hardcoded UI strings violate i18n guidelines
📁 apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx:328
This component has many hardcoded English strings despite importing useTranslation: 'Configure Claude Authentication', 'Add your Claude accounts to enable AI features', 'No accounts configured yet', 'Default', 'Active', 'Authenticated', 'Needs Auth', 'Authenticate', 'Set Active', 'Manual Token Entry'. The nearly identical IntegrationSettings.tsx correctly uses translation keys.
Suggested fix:
Replace hardcoded strings with translation keys. Either reuse existing keys from 'settings:integrations' namespace or add new keys to onboarding.json under an 'oauth' section.
🟠 [da5694d192f2] [HIGH] Error handling inconsistency between chunked and non-chunked writes
📁 apps/frontend/src/main/terminal/pty-manager.ts:183
When an error occurs during a chunked write (line 183-185), the error is caught and logged but NOT re-thrown - the function silently stops. However, when an error occurs during a non-chunked write (line 196-199), the error is caught, logged, AND re-thrown. This inconsistency means callers cannot reliably detect write failures for large data.
Suggested fix:
Make behavior consistent: either don't re-throw in non-chunked path (match chunked behavior), or add callback mechanism to propagate chunked errors. Given fire-and-forget terminal semantics, option 1 (silent logging for both) is likely acceptable.
🟡 [269da98a9987] [MEDIUM] Race condition: terminal destruction during chunked write
📁 apps/frontend/src/main/terminal/pty-manager.ts:190
The function returns immediately via setImmediate(writeChunk) while chunks continue asynchronously. If the terminal is destroyed mid-write, subsequent chunk writes attempt to write to a killed PTY process. The error is caught but this represents undefined behavior with silent partial writes.
Suggested fix:
Add a check at the start of writeChunk to verify terminal.pty is still valid before attempting to write. Could check if terminal is still in the terminals Map, or add an 'isDestroyed' flag to TerminalProcess.
🟡 [43d2e30dfd5c] [MEDIUM] Race condition: rapid successive calls can interleave chunks
📁 apps/frontend/src/main/terminal/pty-manager.ts:190
When writeToPty is called multiple times rapidly with data > 1000 bytes, chunks from different calls can interleave because setImmediate callbacks are queued in FIFO order. For example, two calls with 'AAAA...' and 'BBBB...' could result in 'AABBAA...' being written to the PTY.
Suggested fix:
Implement a write queue at the terminal level that ensures one large write completes before the next begins. Or use a mutex pattern to serialize chunked writes per terminal.
🔵 [af9d6c22ded3] [LOW] Magic numbers in chunked write logic
📁 apps/frontend/src/main/terminal/pty-manager.ts:162
The writeToPty function uses magic numbers 1000 (threshold for chunked writing) and 100 (chunk size) without explanation. These values affect performance and behavior but are not documented or made configurable.
Suggested fix:
Extract to named constants: const CHUNKED_WRITE_THRESHOLD = 1000; const CHUNK_SIZE = 100; Add a comment explaining why these values were chosen.
🟡 [bb3f5317951a] [MEDIUM] Login command logged to console in production
📁 apps/frontend/src/main/ipc-handlers/terminal-handlers.ts:397
Line 397 logs the complete login command to console: 'Login command: '. While this specific command may not contain secrets, logging full commands to console (not debugLog) means this appears in production logs.
Suggested fix:
Replace with debugLog so it only appears when DEBUG=true. Consider whether logging the full command is necessary.
This review was generated by Auto Claude.
Addresses Auto-Claude PR Review feedback: - terminal-handlers.ts: 14 console.log → debugLog - pty-manager.ts: 10 console.log → debugLog/debugError - terminal-manager.ts: 4 console.log → debugLog/debugError Also fixes: - Extract magic numbers to CHUNKED_WRITE_THRESHOLD/CHUNK_SIZE constants - Add terminal validity check before chunked writes - Consistent error handling (no rethrow for fire-and-forget semantics)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/frontend/src/main/ipc-handlers/terminal-handlers.ts (1)
425-432: Remove redundant error logging.Lines 426-427 log the same exception twice: once with
console.errorand once withdebugError. This is redundant and inconsistent with the diagnostic logging approach used throughout the rest of the handler.♻️ Remove the redundant console.error call
} catch (error) { - console.error('[IPC:CLAUDE_PROFILE_INITIALIZE] EXCEPTION:', error); debugError('[IPC] Failed to initialize Claude profile:', error); return { success: false,
🤖 Fix all issues with AI agents
In @apps/frontend/src/main/terminal/pty-manager.ts:
- Around line 176-201: The per-chunk debug noise comes from the two debugLog
calls inside writeChunk (the "Writing chunk" and "Chunk written" logs); reduce
verbosity by removing those per-chunk debugLog calls and instead emit a single
debugLog when the chunked write starts (before first setImmediate loop), retain
the existing completion log (when offset >= data.length) and keep debugError on
catch; update references inside writeChunk, CHUNK_SIZE, terminal.pty and
setImmediate accordingly so behavior stays the same but without per-chunk
logging.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
apps/frontend/src/main/ipc-handlers/terminal-handlers.tsapps/frontend/src/main/terminal/pty-manager.tsapps/frontend/src/main/terminal/terminal-manager.ts
🧰 Additional context used
📓 Path-based instructions (3)
apps/frontend/src/**/*.{ts,tsx,jsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings
Files:
apps/frontend/src/main/ipc-handlers/terminal-handlers.tsapps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/main/terminal/pty-manager.ts
apps/frontend/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Use
useTranslation()hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components
Files:
apps/frontend/src/main/ipc-handlers/terminal-handlers.tsapps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/main/terminal/pty-manager.ts
apps/frontend/**/*.{ts,tsx}
⚙️ CodeRabbit configuration file
apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.
Files:
apps/frontend/src/main/ipc-handlers/terminal-handlers.tsapps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/main/terminal/pty-manager.ts
🧠 Learnings (2)
📓 Common learnings
Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:48.743Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings that should be localized) can be deferred to future i18n cleanup passes rather than requiring immediate fixes in PRs that don't introduce new i18n violations.
📚 Learning: 2025-12-22T22:43:58.052Z
Learnt from: AndyMik90
Repo: AndyMik90/Auto-Claude PR: 150
File: apps/frontend/src/renderer/components/settings/ProjectSettingsContent.tsx:0-0
Timestamp: 2025-12-22T22:43:58.052Z
Learning: In the AndyMik90/Auto-Claude repository, the ESLint configuration only allows `console.warn` and `console.error` levels, not `console.log` or `console.info`.
Applied to files:
apps/frontend/src/main/terminal/terminal-manager.ts
🧬 Code graph analysis (3)
apps/frontend/src/main/ipc-handlers/terminal-handlers.ts (3)
apps/frontend/src/main/claude-profile-manager.ts (1)
getClaudeProfileManager(560-565)apps/frontend/src/main/claude-cli-utils.ts (1)
getClaudeCliInvocationAsync(66-77)apps/frontend/src/shared/utils/shell-escape.ts (1)
escapeShellArg(24-29)
apps/frontend/src/main/terminal/terminal-manager.ts (1)
apps/frontend/src/shared/utils/debug-logger.ts (1)
debugError(25-29)
apps/frontend/src/main/terminal/pty-manager.ts (2)
apps/frontend/src/main/terminal/types.ts (1)
TerminalProcess(8-22)apps/frontend/src/shared/utils/debug-logger.ts (1)
debugError(25-29)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: CodeQL (python)
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (8)
apps/frontend/src/main/terminal/terminal-manager.ts (1)
20-20: LGTM! Debug logging additions improve diagnostics.The added
debugLoganddebugErrorcalls provide useful visibility into terminal write operations without impacting production performance (since they're conditional on debug being enabled). The explicit handling of the "terminal not found" case withdebugErroris a good improvement over the previous silent no-op.Also applies to: 123-133
apps/frontend/src/main/terminal/pty-manager.ts (2)
155-161: LGTM! Constants for chunked write are well-documented.The threshold (1000 bytes) and chunk size (100 bytes) are reasonable for preventing event-loop blocking. The documentation clearly explains the purpose of each constant.
207-215: LGTM! Non-chunked write path with consistent error handling.The error handling correctly matches the chunked path's fire-and-forget semantics, ensuring consistent behavior regardless of data size.
apps/frontend/src/main/ipc-handlers/terminal-handlers.ts (5)
315-325: LGTM: Enhanced diagnostics for profile retrieval.The debug logging added here provides clear visibility into the profile lookup flow, which directly supports the PR objective of troubleshooting integration freeze issues.
336-365: LGTM: Terminal creation logging is thorough.The debug logs around terminal creation and the initialization wait provide good visibility into the async terminal setup flow.
396-403: LGTM: Command execution is well-instrumented.The debug logs before and after the write operation provide clear visibility into command execution timing.
405-424: LGTM: Renderer notification and success flow are correct.The notification flow properly informs the renderer about the auth terminal creation, and the success message provides helpful context.
367-394: Ignoring theenvreturn value creates a fallback risk if Claude CLI detection fails.Line 371 only destructures
commandfromgetClaudeCliInvocationAsync(), discarding theenvthat contains augmented PATH. While the detection logic (detectClaudeAsync) typically returns absolute paths (from Homebrew, NVM, platform standard locations, orfindExecutableAsync), the code's fallback behavior (line 990 in cli-tool-manager.ts) returns just the string'claude'if detection fails. In that scenario, ignoring the env would cause the command to fail.The comment on line 368 assumes the full path will always be available, but defensive handling of the fallback case would be safer. Compare this with the correct pattern used in
claude-integration-handler.ts(lines 542, 625), where bothcommandandenvare destructured and env is passed via pathPrefix.
| const writeChunk = () => { | ||
| // Check if terminal is still valid before writing | ||
| if (!terminal.pty) { | ||
| debugError('[PtyManager:writeToPty] Terminal PTY no longer valid, aborting chunked write'); | ||
| return; | ||
| } | ||
|
|
||
| if (offset >= data.length) { | ||
| debugLog('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum); | ||
| return; | ||
| } | ||
|
|
||
| const chunk = data.slice(offset, offset + CHUNK_SIZE); | ||
| chunkNum++; | ||
| debugLog('[PtyManager:writeToPty] Writing chunk', chunkNum, 'offset:', offset, 'size:', chunk.length); | ||
| try { | ||
| terminal.pty.write(chunk); | ||
| debugLog('[PtyManager:writeToPty] Chunk', chunkNum, 'written'); | ||
| offset += CHUNK_SIZE; | ||
| // Use setImmediate to yield to the event loop between chunks | ||
| setImmediate(writeChunk); | ||
| } catch (error) { | ||
| debugError('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error); | ||
| // Don't rethrow - match non-chunked behavior for consistency (fire-and-forget semantics) | ||
| } | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧹 Nitpick | 🔵 Trivial
Chunked write implementation is correct and addresses the UI freeze.
The use of setImmediate to yield between chunks is the right approach for preventing event-loop blocking. The terminal validity check before each chunk (line 178) and consistent error handling are good defensive practices.
Consider reducing per-chunk log verbosity.
The current logging generates two debugLog calls per chunk (lines 190, 193). For a 10KB write, this produces ~200 log entries. Consider logging only at start, completion, and on error to reduce noise:
♻️ Optional: Reduce per-chunk logging
const writeChunk = () => {
// Check if terminal is still valid before writing
if (!terminal.pty) {
debugError('[PtyManager:writeToPty] Terminal PTY no longer valid, aborting chunked write');
return;
}
if (offset >= data.length) {
debugLog('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum);
return;
}
const chunk = data.slice(offset, offset + CHUNK_SIZE);
chunkNum++;
- debugLog('[PtyManager:writeToPty] Writing chunk', chunkNum, 'offset:', offset, 'size:', chunk.length);
try {
terminal.pty.write(chunk);
- debugLog('[PtyManager:writeToPty] Chunk', chunkNum, 'written');
offset += CHUNK_SIZE;
// Use setImmediate to yield to the event loop between chunks
setImmediate(writeChunk);
} catch (error) {
debugError('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error);
// Don't rethrow - match non-chunked behavior for consistency (fire-and-forget semantics)
}
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const writeChunk = () => { | |
| // Check if terminal is still valid before writing | |
| if (!terminal.pty) { | |
| debugError('[PtyManager:writeToPty] Terminal PTY no longer valid, aborting chunked write'); | |
| return; | |
| } | |
| if (offset >= data.length) { | |
| debugLog('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum); | |
| return; | |
| } | |
| const chunk = data.slice(offset, offset + CHUNK_SIZE); | |
| chunkNum++; | |
| debugLog('[PtyManager:writeToPty] Writing chunk', chunkNum, 'offset:', offset, 'size:', chunk.length); | |
| try { | |
| terminal.pty.write(chunk); | |
| debugLog('[PtyManager:writeToPty] Chunk', chunkNum, 'written'); | |
| offset += CHUNK_SIZE; | |
| // Use setImmediate to yield to the event loop between chunks | |
| setImmediate(writeChunk); | |
| } catch (error) { | |
| debugError('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error); | |
| // Don't rethrow - match non-chunked behavior for consistency (fire-and-forget semantics) | |
| } | |
| }; | |
| const writeChunk = () => { | |
| // Check if terminal is still valid before writing | |
| if (!terminal.pty) { | |
| debugError('[PtyManager:writeToPty] Terminal PTY no longer valid, aborting chunked write'); | |
| return; | |
| } | |
| if (offset >= data.length) { | |
| debugLog('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum); | |
| return; | |
| } | |
| const chunk = data.slice(offset, offset + CHUNK_SIZE); | |
| chunkNum++; | |
| try { | |
| terminal.pty.write(chunk); | |
| offset += CHUNK_SIZE; | |
| // Use setImmediate to yield to the event loop between chunks | |
| setImmediate(writeChunk); | |
| } catch (error) { | |
| debugError('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error); | |
| // Don't rethrow - match non-chunked behavior for consistency (fire-and-forget semantics) | |
| } | |
| }; |
🤖 Prompt for AI Agents
In @apps/frontend/src/main/terminal/pty-manager.ts around lines 176 - 201, The
per-chunk debug noise comes from the two debugLog calls inside writeChunk (the
"Writing chunk" and "Chunk written" logs); reduce verbosity by removing those
per-chunk debugLog calls and instead emit a single debugLog when the chunked
write starts (before first setImmediate loop), retain the existing completion
log (when offset >= data.length) and keep debugError on catch; update references
inside writeChunk, CHUNK_SIZE, terminal.pty and setImmediate accordingly so
behavior stays the same but without per-chunk logging.
|
Pushed additional fixes for Auto-Claude PR Review feedback: ✅ Console.log → DebugLog Replacements
✅ Additional Fixes
⏳ RemainingThe extensive i18n for all hardcoded UI strings in |
|
@aslaker Ready for your final look! 👀 I've addressed the feedback from the Auto-Claude review (console.logs -> debugLog, magic numbers, error handling consistency). As noted above, I'm proposing we handle the remaining extensive i18n changes (30+ keys) in a follow-up PR to keep this freeze fix focused. Could you review and approve so we can merge? 🙏 |
|
|
aslaker
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤖 Auto Claude PR Review
🟠 Follow-up Review: Needs Revision
🟠 Needs revision - 5 unresolved finding(s) from previous review.
Resolution Status
- ✅ Resolved: 5 previous findings addressed
- ❌ Unresolved: 5 previous findings remain
- 🆕 New Issues: 10 new findings in recent changes
Finding Validation
- 🔍 Dismissed as False Positives: 0 findings were re-investigated and found to be incorrect
- ✓ Confirmed Valid: 1 findings verified as genuine issues
- 👤 Needs Human Review: 0 findings require manual verification
🚨 Blocking Issues
- Branch Out of Date: PR branch is behind the base branch and needs to be updated
- quality: [UNRESOLVED] Race condition: rapid successive calls can interleave chunks
- quality: Hardcoded UI strings violate i18n guidelines
- quality: Hardcoded UI strings violate i18n guidelines
Verdict
CI Status: ✅ All 16 checks passing - CI does not block this PR.
Progress Made:
- 6 of 10 previous findings RESOLVED (chunked write implementation, error handling consistency, magic numbers, login command logging, terminal validity checks)
- Alert dialogs replaced with toast notifications ✓
- Toast messages properly use i18n translation keys ✓
- Most console.log statements converted to debugLog ✓
Blocking Issues (MEDIUM severity):
-
Hardcoded UI strings in SDKRateLimitModal.tsx (finding e26db54eba18, partially resolved) - ~15+ hardcoded English strings remain despite toast messages using i18n. Inconsistent with RateLimitModal.tsx which properly uses translations.
-
Hardcoded UI strings in OAuthStep.tsx (finding 706370be0a87, partially resolved) - ~25+ hardcoded English strings remain. Headers, labels, badges, and button text need translation keys.
-
Race condition confirmed valid (finding 43d2e30dfd5c) - finding-validator confirmed the interleaving issue is real. While severity is situational (edge case for terminal writes), this is a documented design gap.
Non-blocking Issues (LOW severity):
- 8 remaining console.error/console.warn calls should use debugError/debugLog for consistency
Required Actions:
- Add i18n translation keys for UI strings in SDKRateLimitModal.tsx (match RateLimitModal.tsx pattern)
- Add i18n translation keys for UI strings in OAuthStep.tsx
- (Optional) Convert remaining console.error to debugError for consistency
- (Future consideration) Add write serialization to chunked PTY writes if interleaving causes issues
Review Process
Agents invoked: resolution-verifier, new-code-reviewer, comment-analyzer, finding-validator
This is an AI-generated follow-up review using parallel specialist analysis with finding validation.
Findings (11 selected of 11 total)
🟡 [43d2e30dfd5c] [MEDIUM] [UNRESOLVED] Race condition: rapid successive calls can interleave chunks
📁 apps/frontend/src/main/terminal/pty-manager.ts:190
When writeToPty is called multiple times rapidly with data > 1000 bytes, chunks from different calls can interleave because setImmediate callbacks are queued in FIFO order. For example, two calls with 'AAAA...' and 'BBBB...' could result in 'AABBAA...' being written to the PTY.
Resolution note: No mutex, queue, or serialization in writeToPty (lines 167-216). setImmediate schedules chunks asynchronously with no inter-call coordination.
Suggested fix:
Implement a write queue at the terminal level that ensures one large write completes before the next begins. Or use a mutex pattern to serialize chunked writes per terminal.
🔵 [NEW-001] [LOW] console.error instead of debugError
📁 apps/frontend/src/main/ipc-handlers/terminal-handlers.ts:59
Line 59 uses console.error instead of the imported debugError function for consistency.
Suggested fix:
Replace with debugError
🔵 [NEW-002] [LOW] Duplicate logging: console.error and debugError
📁 apps/frontend/src/main/ipc-handlers/terminal-handlers.ts:426
Exception handling uses both console.error (line 426) and debugError (line 427) for the same error.
Suggested fix:
Remove duplicate console.error
🔵 [NEW-003] [LOW] console.error instead of debugError
📁 apps/frontend/src/main/ipc-handlers/terminal-handlers.ts:660
Error handling in TERMINAL_RESUME_CLAUDE uses console.error instead of debugError.
Suggested fix:
Replace with debugError
🔵 [NEW-004] [LOW] console.error instead of debugError
📁 apps/frontend/src/main/ipc-handlers/terminal-handlers.ts:671
Error handling in TERMINAL_ACTIVATE_DEFERRED_RESUME uses console.error instead of debugError.
Suggested fix:
Replace with debugError
🔵 [NEW-005] [LOW] console.error instead of debugError
📁 apps/frontend/src/main/terminal/terminal-manager.ts:88
Uses console.error in catch handler despite importing debugError.
Suggested fix:
Replace with debugError
🔵 [NEW-006] [LOW] console.error instead of debugError
📁 apps/frontend/src/main/terminal/terminal-manager.ts:320
Another console.error usage that should use debugError for consistency.
Suggested fix:
Replace with debugError
🔵 [NEW-007] [LOW] console.warn instead of debugLog
📁 apps/frontend/src/main/terminal/pty-manager.ts:88
Uses console.warn for shell spawning info instead of debugLog.
Suggested fix:
Replace with debugLog
🔵 [NEW-008] [LOW] console.warn instead of debugLog
📁 apps/frontend/src/main/terminal/pty-manager.ts:141
Uses console.warn for terminal exit logging instead of debugLog.
Suggested fix:
Replace with debugLog
🟡 [NEW-009] [MEDIUM] Hardcoded UI strings violate i18n guidelines
📁 apps/frontend/src/renderer/components/SDKRateLimitModal.tsx:247
SDKRateLimitModal has ~15+ hardcoded English strings that should use translation keys. Examples: 'Claude Code Rate Limit', 'Upgrade to Pro for Higher Limits', 'Switch Account & Retry', 'Select account...', 'Close', etc. This is inconsistent with RateLimitModal.tsx which properly uses i18n.
Suggested fix:
Apply same i18n pattern as RateLimitModal.tsx
🟡 [NEW-010] [MEDIUM] Hardcoded UI strings violate i18n guidelines
📁 apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx:329
OAuthStep has ~25+ hardcoded English strings despite importing useTranslation. Examples: 'Configure Claude Authentication', 'Add your Claude accounts', 'No accounts configured yet', badge labels ('Default', 'Active', 'Authenticated'), button text, etc. Toast messages correctly use i18n but UI strings do not.
Suggested fix:
Add translation keys for all UI strings in onboarding.json
This review was generated by Auto Claude.
…r + i18n - Replace 8 remaining console.error/warn calls with debugError/debugLog: - terminal-handlers.ts: lines 59, 426, 660, 671 - terminal-manager.ts: lines 88, 320 - pty-manager.ts: lines 88, 141 - Fixed duplicate logging in exception handler - Add comprehensive i18n for SDKRateLimitModal.tsx (~20 strings): - Added rateLimit.sdk.* keys with swap notifications, buttons, labels - EN + FR translations in common.json - Add comprehensive i18n for OAuthStep.tsx (~15 strings): - Added oauth.badges.*, oauth.buttons.*, oauth.labels.* keys - EN + FR translations in onboarding.json All MEDIUM severity findings resolved except race condition (deferred).
PR Review Fixes Complete 🎉Addressed all findings from the Auto Claude PR review: ✅ RESOLVEDconsole.error/warn → debugError/debugLog (8 fixes):
i18n for SDKRateLimitModal.tsx (~20 strings):
i18n for OAuthStep.tsx (~15 strings):
🔄 DEFERRED (Future consideration)
Commit: @aslaker Ready for re-review! 🚀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/frontend/src/renderer/components/SDKRateLimitModal.tsx (1)
247-499: Good i18n coverage with remaining hardcoded strings to address.Most user-facing strings now use translation keys (
t()), which is a significant improvement. However, several hardcoded strings remain in this file:
- Line 329-330: "Recommended: ..." and "Switch to another Claude account..."
- Line 339: "Select account..."
- Line 375: "Add new account..."
- Line 424: "Add another Claude subscription..."
- Line 431: "Add another account:" / "Connect a Claude account:"
- Line 435: "Account name (e.g., Work, Personal)"
- Line 461: "This will open Claude login..."
- Lines 469-472, 481: Upgrade-related strings
Per the PR comments, you've explicitly scoped this work and plan to defer the remaining ~30 keys to a follow-up PR. This aligns with the project's practice of deferring pre-existing i18n issues to focused cleanup passes.
Based on learnings, pre-existing i18n issues can be deferred to future cleanup passes when they don't block the current PR's objectives.
apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx (1)
101-117: FixuseEffectdeps for the OAuth token listener (likely eslint react-hooks warning / stale closures).This effect uses
loadClaudeProfiles()andt(...)but only depends ontoast(Line 116). Please either memoizeloadClaudeProfilesand include deps, or refactor to avoid capturing unstable references.Proposed fix (memoize loader + correct deps)
-import { useState, useEffect } from 'react'; +import { useState, useEffect, useCallback } from 'react'; @@ - const loadClaudeProfiles = async () => { + const loadClaudeProfiles = useCallback(async () => { setIsLoadingProfiles(true); setError(null); try { const result = await window.electronAPI.getClaudeProfiles(); if (result.success && result.data) { setClaudeProfiles(result.data.profiles); setActiveProfileId(result.data.activeProfileId); // Also update the global store await loadGlobalClaudeProfiles(); } } catch (err) { setError(err instanceof Error ? err.message : 'Failed to load profiles'); } finally { setIsLoadingProfiles(false); } - }; + }, []); @@ - }, [toast]); + }, [loadClaudeProfiles, t, toast]);
🤖 Fix all issues with AI agents
In @apps/frontend/src/main/terminal/pty-manager.ts:
- Around line 167-206: writeToPty has a race where concurrent chunked writes
interleave and partial failures continue sending remaining chunks; fix by adding
a per-terminal FIFO write queue (e.g., attach a terminal._writeQueue or
terminal.writeQueue) that enqueues the entire data string as one task and
processes tasks serially so only one chunked writer runs at a time; ensure the
chunked processor checks a real liveness/writable predicate on terminal.pty (not
just truthiness) before each chunk, abort and discard remaining chunks for that
queued task on any write error (log the error) so partial commands are not sent,
then proceed to the next queued task; keep CHUNKED_WRITE_THRESHOLD and
CHUNK_SIZE logic but move chunking to the queue worker and schedule next chunk
via setImmediate to yield.
- Around line 155-162: Update the block comment above CHUNKED_WRITE_THRESHOLD
and CHUNK_SIZE to explicitly state that chunking uses setImmediate between
chunks to intentionally yield to the event loop (to avoid blocking), that
CHUNK_SIZE = 100 is a conservative value chosen for yielding rather than
latency/throughput optimization, and that CHUNKED_WRITE_THRESHOLD = 1000 ensures
small writes bypass chunking; note that performance tuning is optional and not
required for correctness.
In @apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx:
- Around line 159-165: The toast is displaying raw error strings
(initResult.error / result.error) which may expose sensitive internals; instead,
log the full error to the console or a logger (e.g., console.error or a provided
logger) inside the same block where loadClaudeProfiles() and toast(...) are
called, and pass a localized, user-safe message to toast using
t('oauth.toast.authStartFailed') or t('oauth.toast.tryAgain'); for the other
occurrences (the blocks around the result.error usages at ~lines 240-245 and
296-301) do the same: log the raw error and show only a sanitized/localized
message in the toast (optionally include a non-sensitive short code if you
extract/sanitize it before showing).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (9)
apps/frontend/src/main/ipc-handlers/terminal-handlers.tsapps/frontend/src/main/terminal/pty-manager.tsapps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/shared/i18n/locales/en/common.jsonapps/frontend/src/shared/i18n/locales/en/onboarding.jsonapps/frontend/src/shared/i18n/locales/fr/common.jsonapps/frontend/src/shared/i18n/locales/fr/onboarding.json
🧰 Additional context used
📓 Path-based instructions (4)
apps/frontend/src/**/*.{ts,tsx,jsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings
Files:
apps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/main/terminal/pty-manager.tsapps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/main/ipc-handlers/terminal-handlers.ts
apps/frontend/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Use
useTranslation()hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components
Files:
apps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/main/terminal/pty-manager.tsapps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/main/ipc-handlers/terminal-handlers.ts
apps/frontend/**/*.{ts,tsx}
⚙️ CodeRabbit configuration file
apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.
Files:
apps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/main/terminal/pty-manager.tsapps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/main/terminal/terminal-manager.tsapps/frontend/src/main/ipc-handlers/terminal-handlers.ts
apps/frontend/src/shared/i18n/locales/**/*.json
📄 CodeRabbit inference engine (CLAUDE.md)
apps/frontend/src/shared/i18n/locales/**/*.json: Store translation strings in namespace-organized JSON files atapps/frontend/src/shared/i18n/locales/{lang}/*.jsonfor each supported language
When implementing new frontend features, add translation keys to all language files (minimum: en/.json and fr/.json)
Files:
apps/frontend/src/shared/i18n/locales/en/onboarding.jsonapps/frontend/src/shared/i18n/locales/en/common.jsonapps/frontend/src/shared/i18n/locales/fr/onboarding.jsonapps/frontend/src/shared/i18n/locales/fr/common.json
🧠 Learnings (6)
📓 Common learnings
Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:48.743Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings that should be localized) can be deferred to future i18n cleanup passes rather than requiring immediate fixes in PRs that don't introduce new i18n violations.
📚 Learning: 2025-12-30T16:38:36.314Z
Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/frontend/src/**/*.{ts,tsx,jsx} : Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings
Applied to files:
apps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/renderer/components/onboarding/OAuthStep.tsx
📚 Learning: 2025-12-30T16:38:36.314Z
Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/frontend/src/**/*.{ts,tsx} : Use `useTranslation()` hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components
Applied to files:
apps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/renderer/components/onboarding/OAuthStep.tsx
📚 Learning: 2025-12-30T16:38:36.314Z
Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/frontend/src/shared/i18n/locales/**/*.json : When implementing new frontend features, add translation keys to all language files (minimum: en/*.json and fr/*.json)
Applied to files:
apps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/renderer/components/onboarding/OAuthStep.tsxapps/frontend/src/shared/i18n/locales/en/onboarding.jsonapps/frontend/src/shared/i18n/locales/en/common.jsonapps/frontend/src/shared/i18n/locales/fr/onboarding.jsonapps/frontend/src/shared/i18n/locales/fr/common.json
📚 Learning: 2026-01-04T23:59:45.209Z
Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:45.209Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings) can be deferred for future i18n cleanup passes. Do not fix such issues in PRs that do not introduce new i18n violations, especially in frontend TSX components (e.g., apps/frontend/**/*.tsx). If a PR adds new i18n violations, address them in that PR.
Applied to files:
apps/frontend/src/renderer/components/SDKRateLimitModal.tsxapps/frontend/src/renderer/components/onboarding/OAuthStep.tsx
📚 Learning: 2025-12-22T22:43:58.052Z
Learnt from: AndyMik90
Repo: AndyMik90/Auto-Claude PR: 150
File: apps/frontend/src/renderer/components/settings/ProjectSettingsContent.tsx:0-0
Timestamp: 2025-12-22T22:43:58.052Z
Learning: In the AndyMik90/Auto-Claude repository, the ESLint configuration only allows `console.warn` and `console.error` levels, not `console.log` or `console.info`.
Applied to files:
apps/frontend/src/main/terminal/terminal-manager.ts
🧬 Code graph analysis (5)
apps/frontend/src/renderer/components/SDKRateLimitModal.tsx (2)
apps/frontend/src/renderer/hooks/use-toast.ts (2)
useToast(192-192)toast(192-192)apps/frontend/src/renderer/components/ui/dialog.tsx (3)
DialogTitle(124-124)DialogDescription(125-125)DialogFooter(123-123)
apps/frontend/src/main/terminal/pty-manager.ts (2)
apps/frontend/src/main/terminal/types.ts (1)
TerminalProcess(8-22)apps/frontend/src/shared/utils/debug-logger.ts (1)
debugError(25-29)
apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx (2)
apps/frontend/src/renderer/hooks/use-toast.ts (2)
useToast(192-192)toast(192-192).design-system/src/lib/icons.ts (2)
Star(34-34)Check(21-21)
apps/frontend/src/main/terminal/terminal-manager.ts (1)
apps/frontend/src/shared/utils/debug-logger.ts (1)
debugError(25-29)
apps/frontend/src/main/ipc-handlers/terminal-handlers.ts (4)
apps/frontend/src/shared/utils/debug-logger.ts (1)
debugError(25-29)apps/frontend/src/main/claude-profile-manager.ts (1)
getClaudeProfileManager(560-565)apps/frontend/src/main/claude-cli-utils.ts (1)
getClaudeCliInvocationAsync(66-77)apps/frontend/src/shared/utils/shell-escape.ts (1)
escapeShellArg(24-29)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: CodeQL
- GitHub Check: CodeQL (python)
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (13)
apps/frontend/src/shared/i18n/locales/fr/common.json (1)
150-183: LGTM! French translations are accurate with complete key parity.The French translations are grammatically correct, follow proper French typographic conventions (guillemets, accents), and all variable placeholders are correctly preserved. Key parity with the English locale is confirmed—all keys in
rateLimit.toastandrateLimit.sdkmatch exactly betweenfr/common.jsonanden/common.json.apps/frontend/src/shared/i18n/locales/en/common.json (1)
150-183: LGTM! Clean i18n structure for rate limit notifications.The new translation keys are well-organized under
rateLimit.sourceswith clear separation betweentoast(notification messages) andsdk(modal UI strings). The structure is consistent with existing patterns, and according to the PR context, corresponding French translations have been added.apps/frontend/src/shared/i18n/locales/fr/onboarding.json (1)
34-77: LGTM! Complete French translations for OAuth flow.The French translations are comprehensive and properly structured, mirroring the English locale structure. This fulfills the coding guideline requirement to add translation keys to all language files (minimum en + fr).
apps/frontend/src/main/terminal/terminal-manager.ts (1)
20-20: LGTM! Consistent use of debug logging utilities.The changes correctly replace
console.errorwithdebugErrorand add helpful debug traces in the write flow. This aligns with the project's ESLint configuration that restricts console usage to warn/error levels only.Based on learnings, the project prefers centralized debug logging utilities over direct console usage.
Also applies to: 88-88, 124-132, 320-320
apps/frontend/src/renderer/components/SDKRateLimitModal.tsx (2)
2-2: LGTM! Proper setup for i18n and non-blocking notifications.The imports and hook initialization correctly establish i18n support and toast notifications, replacing the previous blocking alert dialogs with a better UX.
Also applies to: 25-25, 60-61
167-187: Excellent improvement: non-blocking toasts with i18n.The replacement of blocking
alert()dialogs withtoast()notifications significantly improves UX by:
- Not blocking the event loop during profile authentication
- Using localized messages via
t()calls- Providing consistent visual feedback
The error handling properly uses the
destructivevariant for error toasts.apps/frontend/src/main/ipc-handlers/terminal-handlers.ts (2)
59-59: LGTM! Consistent error logging with debug utilities.The replacement of
console.errorwithdebugErroraligns with project logging standards and provides centralized debug control.Also applies to: 659-659, 670-670
315-427: Excellent diagnostic improvements and simplified CLI invocation.The changes provide comprehensive debugging for the Claude profile initialization flow:
Debug logging enhancements:
- Traces each step of profile initialization (profile lookup, config dir creation, terminal creation, command construction)
- Logs key decision points and data (profile existence, terminal creation success, command details)
- Appropriate detail level for troubleshooting complex OAuth flows without being excessive
CLI invocation simplification (lines 369-398):
- Now uses
getClaudeCliInvocationAsync()to obtain the absolute Claude CLI path- Eliminates PATH manipulation in favor of direct absolute path usage
- Properly escapes commands using OS-specific functions:
escapeShellArgWindows()for Windows cmd.exeescapeShellArg()for POSIX shells (bash/zsh)- Correct environment variable syntax for each OS:
- Windows:
set "VAR=value" && %VAR%- POSIX:
export VAR=value && $VARThe security posture is solid with proper escaping, and the diagnostic improvements will significantly aid troubleshooting.
apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx (2)
30-31: Toast integration is clean and localized.Also applies to: 45-47
107-112: Good: replaced blocking alerts / hardcoded UI strings witht('oauth.*')+ non-blocking toasts.Also applies to: 169-174, 250-255, 291-295, 304-308, 328-333, 364-366, 395-396, 457-473, 499-511, 679-694
apps/frontend/src/shared/i18n/locales/en/onboarding.json (1)
34-77: No action needed—EN/FR parity for oauth keys is already complete.Both
en/onboarding.jsonandfr/onboarding.jsoncontain all the sameoauth.*keys with matching structure, includingoauth.toast.authSuccessWithEmailwith the{{email}}placeholder properly preserved in both files.Likely an incorrect or invalid review comment.
apps/frontend/src/main/terminal/pty-manager.ts (2)
13-13: LGTM: Debug logging migration.The replacement of
console.log/console.warnwithdebugLogimproves observability and aligns with the project's enhanced diagnostics strategy.Also applies to: 88-88, 141-141
207-215: Add tests forwriteToPtyerror scenarios and review chunked write logging verbosity.The
writeToPtyfunction (lines 167–216) has no dedicated test coverage. No tests verify error handling for PTY write failures or invalid terminals during chunked writes. Additionally, the chunked write path (triggered for data > 1000 bytes) logs extensively: for a 1.1 KB write, approximately 27 debug messages are emitted (per-chunk logs at lines 190, 193, plus lifecycle logs at 168, 172, 184, 204, 206). Clarify whether this verbosity level is intentional or if it should be reduced to critical lifecycle events only.
| /** | ||
| * Constants for chunked write behavior | ||
| * CHUNKED_WRITE_THRESHOLD: Data larger than this (bytes) will be written in chunks | ||
| * CHUNK_SIZE: Size of each chunk - smaller chunks yield to event loop more frequently | ||
| */ | ||
| const CHUNKED_WRITE_THRESHOLD = 1000; | ||
| const CHUNK_SIZE = 100; | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧹 Nitpick | 🔵 Trivial
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for CHUNK_SIZE and chunked write related references
echo "=== Searching for CHUNK_SIZE and chunked write references ==="
rg -n "CHUNK_SIZE|chunked.*write|CHUNKED_WRITE" --type=ts --type=tsx --type=md -C 2Repository: AndyMik90/Auto-Claude
Length of output: 171
🏁 Script executed:
#!/bin/bash
# Check for performance tests or benchmarks
echo "=== Looking for performance tests or benchmarks ==="
fd -e test.ts -e test.tsx -e spec.ts -e bench.ts | xargs rg -l "chunk|pty|terminal|write" 2>/dev/null || echo "No test files found with those patterns"Repository: AndyMik90/Auto-Claude
Length of output: 3092
🏁 Script executed:
#!/bin/bash
# Get the full context of pty-manager.ts around the constants and their usage
echo "=== Examining pty-manager.ts file size ==="
wc -l apps/frontend/src/main/terminal/pty-manager.tsRepository: AndyMik90/Auto-Claude
Length of output: 158
🏁 Script executed:
#!/bin/bash
# Read the pty-manager.ts file to understand context and usage
echo "=== Reading pty-manager.ts ==="
cat -n apps/frontend/src/main/terminal/pty-manager.tsRepository: AndyMik90/Auto-Claude
Length of output: 9408
🏁 Script executed:
#!/bin/bash
# Simpler search for CHUNK_SIZE and related constants
echo "=== Searching for CHUNK_SIZE usage ==="
rg -n "CHUNK_SIZE|CHUNKED_WRITE_THRESHOLD|setImmediate" apps/frontend/src/main/terminal/ -C 3Repository: AndyMik90/Auto-Claude
Length of output: 4038
The chunked write approach is sound, though the rationale for specific chunk size could be clearer.
The constants are well-extracted and documented. However, the logic is intentionally designed to yield to the event loop via setImmediate between chunks—this is not a latency concern but the intended behavior to prevent blocking. CHUNK_SIZE of 100 bytes is conservative by design for this purpose, and the 1000-byte threshold ensures small writes bypass chunking entirely. While performance testing could validate whether the chunk size is optimal for actual throughput, it is not necessary for correctness, as the current values are reasonable for a terminal I/O operation.
🤖 Prompt for AI Agents
In @apps/frontend/src/main/terminal/pty-manager.ts around lines 155 - 162,
Update the block comment above CHUNKED_WRITE_THRESHOLD and CHUNK_SIZE to
explicitly state that chunking uses setImmediate between chunks to intentionally
yield to the event loop (to avoid blocking), that CHUNK_SIZE = 100 is a
conservative value chosen for yielding rather than latency/throughput
optimization, and that CHUNKED_WRITE_THRESHOLD = 1000 ensures small writes
bypass chunking; note that performance tuning is optional and not required for
correctness.
| export function writeToPty(terminal: TerminalProcess, data: string): void { | ||
| terminal.pty.write(data); | ||
| debugLog('[PtyManager:writeToPty] About to write to pty, data length:', data.length); | ||
|
|
||
| // For large commands, write in chunks to prevent blocking | ||
| if (data.length > CHUNKED_WRITE_THRESHOLD) { | ||
| debugLog('[PtyManager:writeToPty] Large write detected, using chunked write'); | ||
| let offset = 0; | ||
| let chunkNum = 0; | ||
|
|
||
| const writeChunk = () => { | ||
| // Check if terminal is still valid before writing | ||
| if (!terminal.pty) { | ||
| debugError('[PtyManager:writeToPty] Terminal PTY no longer valid, aborting chunked write'); | ||
| return; | ||
| } | ||
|
|
||
| if (offset >= data.length) { | ||
| debugLog('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum); | ||
| return; | ||
| } | ||
|
|
||
| const chunk = data.slice(offset, offset + CHUNK_SIZE); | ||
| chunkNum++; | ||
| debugLog('[PtyManager:writeToPty] Writing chunk', chunkNum, 'offset:', offset, 'size:', chunk.length); | ||
| try { | ||
| terminal.pty.write(chunk); | ||
| debugLog('[PtyManager:writeToPty] Chunk', chunkNum, 'written'); | ||
| offset += CHUNK_SIZE; | ||
| // Use setImmediate to yield to the event loop between chunks | ||
| setImmediate(writeChunk); | ||
| } catch (error) { | ||
| debugError('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error); | ||
| // Don't rethrow - match non-chunked behavior for consistency (fire-and-forget semantics) | ||
| } | ||
| }; | ||
|
|
||
| // Start the chunked write after yielding | ||
| debugLog('[PtyManager:writeToPty] Scheduling first chunk...'); | ||
| setImmediate(writeChunk); | ||
| debugLog('[PtyManager:writeToPty] First chunk scheduled, returning'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Critical: Race condition with concurrent chunked writes.
The chunked write implementation has a critical concurrency bug: if writeToPty is called multiple times on the same terminal before previous chunks complete, the chunks will interleave at the PTY level, corrupting the input stream.
Example scenario:
writeToPty(terminal, longCommand1)starts writing chunk 1writeToPty(terminal, longCommand2)is called before longCommand1 finishes- Both create independent
writeChunkclosures scheduled viasetImmediate - Chunks write in unpredictable order: cmd1-chunk1, cmd2-chunk1, cmd1-chunk2, cmd2-chunk2...
- Result: corrupted terminal input
Additional major issue (Lines 197-200):
If a chunk write fails mid-stream, the error is logged but subsequent chunks continue writing. This sends partial/corrupted commands to the terminal. Unlike the non-chunked path (where a single write either succeeds or fails atomically), partial chunked writes can leave the terminal in an inconsistent state.
Minor issue (Line 178):
The validity check if (!terminal.pty) only confirms the property exists, not that the PTY is alive/writable.
🔒 Recommended fix: Add write queue to serialize concurrent writes
Introduce a per-terminal write queue to prevent interleaving:
+// Map of terminal ID to write queue (array of pending write operations)
+const writeQueues = new Map<string, Array<{data: string, offset: number}>>();
+const isWriting = new Map<string, boolean>();
+
export function writeToPty(terminal: TerminalProcess, data: string): void {
debugLog('[PtyManager:writeToPty] About to write to pty, data length:', data.length);
if (data.length > CHUNKED_WRITE_THRESHOLD) {
+ // Queue this write if another is in progress
+ if (isWriting.get(terminal.id)) {
+ const queue = writeQueues.get(terminal.id) || [];
+ queue.push({ data, offset: 0 });
+ writeQueues.set(terminal.id, queue);
+ debugLog('[PtyManager:writeToPty] Queued write, queue length:', queue.length);
+ return;
+ }
+
+ isWriting.set(terminal.id, true);
debugLog('[PtyManager:writeToPty] Large write detected, using chunked write');
let offset = 0;
let chunkNum = 0;
const writeChunk = () => {
if (!terminal.pty) {
debugError('[PtyManager:writeToPty] Terminal PTY no longer valid, aborting chunked write');
+ isWriting.set(terminal.id, false);
+ processNextQueuedWrite(terminal);
return;
}
if (offset >= data.length) {
debugLog('[PtyManager:writeToPty] Chunked write completed, total chunks:', chunkNum);
+ isWriting.set(terminal.id, false);
+ processNextQueuedWrite(terminal);
return;
}
const chunk = data.slice(offset, offset + CHUNK_SIZE);
chunkNum++;
debugLog('[PtyManager:writeToPty] Writing chunk', chunkNum, 'offset:', offset, 'size:', chunk.length);
try {
terminal.pty.write(chunk);
debugLog('[PtyManager:writeToPty] Chunk', chunkNum, 'written');
offset += CHUNK_SIZE;
setImmediate(writeChunk);
} catch (error) {
debugError('[PtyManager:writeToPty] Chunked write FAILED at chunk', chunkNum, 'offset', offset, ':', error);
- // Don't rethrow - match non-chunked behavior for consistency (fire-and-forget semantics)
+ // Abort remaining chunks on error to prevent partial command corruption
+ isWriting.set(terminal.id, false);
+ processNextQueuedWrite(terminal);
+ return;
}
};
debugLog('[PtyManager:writeToPty] Scheduling first chunk...');
setImmediate(writeChunk);
debugLog('[PtyManager:writeToPty] First chunk scheduled, returning');
} else {
try {
terminal.pty.write(data);
debugLog('[PtyManager:writeToPty] Write completed successfully');
} catch (error) {
debugError('[PtyManager:writeToPty] Write FAILED:', error);
}
}
}
+
+function processNextQueuedWrite(terminal: TerminalProcess): void {
+ const queue = writeQueues.get(terminal.id);
+ if (!queue || queue.length === 0) {
+ writeQueues.delete(terminal.id);
+ return;
+ }
+
+ const next = queue.shift()!;
+ if (queue.length === 0) {
+ writeQueues.delete(terminal.id);
+ }
+
+ writeToPty(terminal, next.data);
+}Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In @apps/frontend/src/main/terminal/pty-manager.ts around lines 167 - 206,
writeToPty has a race where concurrent chunked writes interleave and partial
failures continue sending remaining chunks; fix by adding a per-terminal FIFO
write queue (e.g., attach a terminal._writeQueue or terminal.writeQueue) that
enqueues the entire data string as one task and processes tasks serially so only
one chunked writer runs at a time; ensure the chunked processor checks a real
liveness/writable predicate on terminal.pty (not just truthiness) before each
chunk, abort and discard remaining chunks for that queued task on any write
error (log the error) so partial commands are not sent, then proceed to the next
queued task; keep CHUNKED_WRITE_THRESHOLD and CHUNK_SIZE logic but move chunking
to the queue worker and schedule next chunk via setImmediate to yield.
| await loadClaudeProfiles(); | ||
| alert(`Failed to start authentication: ${initResult.error || 'Please try again.'}`); | ||
| toast({ | ||
| variant: 'destructive', | ||
| title: t('oauth.toast.authStartFailed'), | ||
| description: initResult.error || t('oauth.toast.tryAgain'), | ||
| }); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid showing raw *.error strings in user-facing toasts unless they’re guaranteed “safe”.
initResult.error / result.error may contain technical details (paths, internal codes, etc.). Prefer logging the raw error and showing a localized, user-safe message in the toast.
Safer UX pattern (keep details out of the toast)
toast({
variant: 'destructive',
title: t('oauth.toast.authStartFailed'),
- description: initResult.error || t('oauth.toast.tryAgain'),
+ description: t('oauth.toast.tryAgain'),
});Also applies to: 240-245, 296-301
🤖 Prompt for AI Agents
In @apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx around lines
159 - 165, The toast is displaying raw error strings (initResult.error /
result.error) which may expose sensitive internals; instead, log the full error
to the console or a logger (e.g., console.error or a provided logger) inside the
same block where loadClaudeProfiles() and toast(...) are called, and pass a
localized, user-safe message to toast using t('oauth.toast.authStartFailed') or
t('oauth.toast.tryAgain'); for the other occurrences (the blocks around the
result.error usages at ~lines 240-245 and 296-301) do the same: log the raw
error and show only a sanitized/localized message in the toast (optionally
include a non-sensitive short code if you extract/sanitize it before showing).
AlexMadera
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤖 Auto Claude PR Review
Merge Verdict: 🟠 NEEDS REVISION
🟠 Needs revision - 2 issue(s) require attention.
2 issue(s) must be addressed (0 required, 2 recommended), 3 suggestions
Risk Assessment
| Factor | Level | Notes |
|---|---|---|
| Complexity | High | Based on lines changed |
| Security Impact | None | Based on security findings |
| Scope Coherence | Good | Based on structural review |
Findings Summary
- Medium: 2 issue(s)
- Low: 3 issue(s)
Generated by Auto Claude PR Review
Findings (5 selected of 5 total)
🟡 [4051d875f312] [MEDIUM] Theoretical race condition in chunked write mechanism
📁 apps/frontend/src/main/terminal/pty-manager.ts:176
The chunked write implementation uses closures over offset and data variables. If writeToPty() is called concurrently for the same terminal before the first write completes, chunks from different calls could interleave, causing data corruption. The function returns immediately while chunks continue writing asynchronously.
Suggested fix:
Add a write queue per terminal or a mutex lock to serialize concurrent writes. Alternatively, document that writeToPty() must not be called concurrently and add an assertion to detect violations.
🟡 [b56431a47a41] [MEDIUM] Excessive debug logging in writeToPty function
📁 apps/frontend/src/main/terminal/pty-manager.ts:167
The writeToPty function contains 13 debugLog/debugError calls. This is excessive for production code and adds noise. The detailed logging of every chunk (including offset and size) will flood logs during normal operation.
Suggested fix:
Reduce logging to 2-3 key points: function entry, chunked write start, and completion/error. Remove per-chunk logging. Consider gating debug logs behind a DEBUG environment variable.
🔵 [624ecfb26ca1] [LOW] Magic numbers for chunk size configuration
📁 apps/frontend/src/main/terminal/pty-manager.ts:160
CHUNKED_WRITE_THRESHOLD (1000) and CHUNK_SIZE (100) are magic numbers defined as constants but without documentation explaining their rationale. These values affect performance and the effectiveness of preventing UI freezes.
Suggested fix:
Add JSDoc comments explaining the trade-offs: larger CHUNK_SIZE reduces overhead but may still cause brief blocking; smaller chunks yield more often but increase write overhead. Mention that these were empirically chosen.
🔵 [661c197b066d] [LOW] Excessive debug logging in IPC handler
📁 apps/frontend/src/main/ipc-handlers/terminal-handlers.ts:315
The CLAUDE_PROFILE_INITIALIZE handler contains 20+ debugLog calls. This is overly verbose for production code.
Suggested fix:
Reduce to essential logging points: handler entry, profile lookup success/failure, terminal creation success/failure, and command execution. Remove step-by-step logging.
🔵 [e8001b0b22a5] [LOW] Inconsistent error logging - console.error not converted to debugLog
📁 apps/frontend/src/renderer/components/settings/IntegrationSettings.tsx:232
While most logging was converted to debugLog, line 232 still uses console.error. This is inconsistent with the project's logging utility.
Suggested fix:
Replace with debugError('[IntegrationSettings] Failed to authenticate profile:', err) for consistency.
This review was generated by Auto Claude.
AndyMik90
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤖 Auto Claude PR Review
🟠 Follow-up Review: Needs Revision
🟠 Needs revision - 1 unresolved finding(s) from previous review.
Resolution Status
- ✅ Resolved: 0 previous findings addressed
- ❌ Unresolved: 1 previous findings remain
- 🆕 New Issues: 1 new findings in recent changes
Finding Validation
- 🔍 Dismissed as False Positives: 0 findings were re-investigated and found to be incorrect
- ✓ Confirmed Valid: 1 findings verified as genuine issues
- 👤 Needs Human Review: 0 findings require manual verification
🚨 Blocking Issues
- quality: Race condition in chunked PTY writes
Verdict
CI Status: ⏳ 1 CI check pending - Cannot give READY_TO_MERGE until CI completes.
Blocking Issues:
- NEW-002 (LOW, CONFIRMED_VALID): Missing 't' in useEffect dependency array in OAuthStep.tsx:116. Was flagged in previous review and remains unfixed. Should be
[t, toast]not[toast]. - NEW-001 (MEDIUM): Race condition in chunked PTY write implementation. Concurrent large writes can interleave chunks, corrupting terminal input.
Progress Acknowledged:
- ✅ console.error/warn → debugError/debugLog (8 fixes)
- ✅ Alert dialogs replaced with i18n toast notifications
- ✅ Translation keys added to en/fr locale files
Required Actions:
- Wait for CI to complete
- Fix OAuthStep.tsx line 116: change
[toast]to[t, toast] - Address race condition in pty-manager.ts chunked writes (add write serialization per terminal)
Out-of-Scope Issues Filtered:
- CodeRabbit's i18n findings for lines 328, 339, 375, etc. in SDKRateLimitModal.tsx are in unchanged code sections (pre-existing)
- Hardcoded strings in Terminal.tsx, settings-store.ts, TaskDetailModal.tsx are in files not modified by this PR
Review Process
Agents invoked: resolution-verifier, new-code-reviewer, comment-analyzer, finding-validator
This is an AI-generated follow-up review using parallel specialist analysis with finding validation.
Findings (2 selected of 2 total)
🔵 [NEW-002] [LOW] [UNRESOLVED] Previous finding NEW-001 not addressed: Missing 't' in useEffect dependency array
📁 apps/frontend/src/renderer/components/onboarding/OAuthStep.tsx:116
The useEffect at line 102-116 uses the translation function 't' inside the callback but only includes 'toast' in the dependency array. IntegrationSettings.tsx correctly uses [t, toast] for the same pattern at line 98. This is a minor React hooks exhaustive-deps violation, but the 't' function from useTranslation is stable and unlikely to cause runtime issues.
Resolution note: // OAuthStep.tsx lines 102-116:
useEffect(() => {
const unsubscribe = window.electronAPI.onTerminalOAuthToken(async (info) => {
if (info.success && info.profileId) {
await loadClaudeProfiles();
toast({
title: t('oauth.toast.authSuccess'),
description: info.email ? t('oauth.toast.authSuccessWithEmail', { email: info.email }) : t('oauth.toast.authSuccessGeneric'),
});
}
});
return unsubscribe;
}, [toast]); // <-- Still missing 't' in dependency array
Suggested fix:
Add 't' to the dependency array: }, [toast, t]); (matching IntegrationSettings.tsx pattern)
🟡 [NEW-001] [MEDIUM] Race condition in chunked PTY writes
📁 apps/frontend/src/main/terminal/pty-manager.ts:167
The chunked write implementation lacks synchronization. When writeToPty is called with large data (>1000 bytes), it schedules chunks via setImmediate and returns immediately. If another write call occurs before all chunks are written, the data from both writes will interleave at the PTY level. This is possible because TERMINAL_INPUT uses ipcMain.on which can fire multiple events asynchronously. While unlikely in normal typing, rapid paste operations combined with user input could trigger this.
Suggested fix:
Add a per-terminal write queue that ensures writes complete in order. Alternatively, use a Map<terminalId, Promise> to track pending writes and chain new writes to wait for completion.
This review was generated by Auto Claude.
Summary
Fixes ACS-175. Resolves UI freeze issues during Claude profile integration setup and improves rate limit modal handling for a smoother onboarding experience.
Problem
alert()dialogs disrupt user experience during rate limit handling and authentication flowsSolution
alert()dialogs with modern toast notificationsdebugLogcalls for better troubleshootingChanges
terminal-handlers.tspty-manager.tsterminal-manager.tsRateLimitModal.tsxalert()withuseToast()notificationsSDKRateLimitModal.tsxuseTranslation, replacedalert()with i18n toastsOAuthStep.tsxIntegrationSettings.tsxconsole.logwithdebugLogutilityen/settings.jsonfr/settings.jsonen/common.jsonfr/common.jsonen/onboarding.jsonfr/onboarding.jsonCode Review Fixes Applied
Addressed all CodeRabbit feedback:
OAuthStep.tsxt('oauth.toast.*')i18n callsRateLimitModal.tsxt('rateLimit.toast.*')callsSDKRateLimitModal.tsxuseTranslationhook + i18n toast callsconsole.loginIntegrationSettings.tsxdebugLogfrom debug-logger utilityTest Plan
debugLoginstead ofconsole.log🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Chores
Localization
✏️ Tip: You can customize this high-level summary in your review settings.