Setup project build infrastructure for leaked Claude Code source#7
Setup project build infrastructure for leaked Claude Code source#7UbaidUllah9962 wants to merge 7 commits intotanbiralam:mainfrom
Conversation
Create stub exports for 17 missing tool modules that are referenced by the codebase via require() or import statements. Each stub exports the expected symbol as null (or a no-op function/component) to prevent runtime crashes when the modules are conditionally loaded. Stubs created: - TungstenTool (with TungstenLiveMonitor no-op component) - SuggestBackgroundPRTool, SleepTool, MonitorTool - SendUserFileTool, PushNotificationTool, SubscribePRTool - OverflowTestTool, CtxInspectTool, TerminalCaptureTool - WebBrowserTool, SnipTool, ListPeersTool - WorkflowTool (with bundled/index.ts initBundledWorkflows) - VerifyPlanExecutionTool, REPLTool Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: UbaidUllah9962 <165874963+UbaidUllah9962@users.noreply.github.com>
Create 73 minimal stub files for internal modules that are imported by existing source files but don't exist on disk. Each stub exports the expected names (types, interfaces, functions, constants, or default exports) based on analysis of all import statements across the codebase. Categories of stubs created: - Type/interface-only modules (e.g., types/message.ts, types/tools.ts) - SDK type definitions (entrypoints/sdk/*.ts) - Skill markdown content modules (skills/bundled/**/*.md.ts) - Service types (services/oauth/types.ts, services/lsp/types.ts, etc.) - Component types (components/mcp/types.ts, components/wizard/types.ts) - Utility modules (utils/filePersistence/types.ts, types/connectorText.ts) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: UbaidUllah9962 <165874963+UbaidUllah9962@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: UbaidUllah9962 <165874963+UbaidUllah9962@users.noreply.github.com>
…ipts - Created package.json with all ~80 dependencies (public npm + local stubs for private @ant/* packages) - Created tsconfig.json for TypeScript with Bun/ESNext/JSX support - Created bunfig.toml with MACRO defines and bun:bundle preload plugin - Created plugins/bunBundleDev.ts to polyfill bun:bundle feature() at runtime - Created stubs/ for private Anthropic packages (@ant/*, @anthropic-ai/mcpb, @anthropic-ai/sandbox-runtime) - Created type declarations for bun:bundle and MACRO globals - Created ~90 stub files for missing internal modules not included in the leaked source - Fixed Commander.js -d2e flag incompatibility - Upgraded React to canary (19.x) for compiler-runtime and react-reconciler compatibility - Updated README with Quick Setup instructions Agent-Logs-Url: https://github.com/UbaidUllah9962/claude-code-agent/sessions/99df9f0c-eb97-4c01-85fd-a9fdd02a7b8f Co-authored-by: UbaidUllah9962 <165874963+UbaidUllah9962@users.noreply.github.com>
Agent-Logs-Url: https://github.com/UbaidUllah9962/claude-code-agent/sessions/99df9f0c-eb97-4c01-85fd-a9fdd02a7b8f Co-authored-by: UbaidUllah9962 <165874963+UbaidUllah9962@users.noreply.github.com>
…onment Setup project build infrastructure for leaked Claude Code source
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds a Bun-based CLI scaffold: project config, Bun plugin and define macros, a package manifest and scripts, TypeScript config and many type/tool/component stub modules and package stubs; README quick-start and .gitignore included. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 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🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 18
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
🟡 Minor comments (9)
src/components/ui/option.ts-2-2 (1)
2-2:⚠️ Potential issue | 🟡 Minor
Optioninterface lacks type safety and is used without explicit shape constraints.The empty interface
export interface Option {}is too permissive—it accepts any non-nullish value in TypeScript. This weakens type safety insrc/components/permissions/rules/PermissionRuleList.tsxwhere it's imported and used asoptions: Option[].Use a stricter placeholder until the real model is defined:
Proposed change
- export interface Option {} + // TODO: Replace with upstream Option shape when available. + export type Option = Record<string, unknown>;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/ui/option.ts` at line 2, The empty export interface Option {} is too permissive; replace it with a minimal strongly-typed placeholder (e.g., include required fields like id: string and label: string or make it generic as Option<T = string | number> { id: string; label: string; value?: T }) and update usages that expect options: Option[] (notably in PermissionRuleList.tsx) to match the new shape or generic parameter; ensure imports of Option remain and adjust any property access in PermissionRuleList (e.g., option.id, option.label, or option.value) to the new fields so TS enforces the shape until the real model is defined.stubs/@ant/computer-use-mcp/types.js-1-1 (1)
1-1:⚠️ Potential issue | 🟡 MinorPrevent accidental mutation of shared default flags.
DEFAULT_GRANT_FLAGSis mutable and can be changed by any importer. Freezing the object would avoid cross-module state leaks.Proposed change
-export const DEFAULT_GRANT_FLAGS = {}; +export const DEFAULT_GRANT_FLAGS = Object.freeze({});🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stubs/`@ant/computer-use-mcp/types.js at line 1, DEFAULT_GRANT_FLAGS is exported as a plain mutable object which allows importers to accidentally mutate shared state; make the export immutable by freezing the object (e.g., use Object.freeze on DEFAULT_GRANT_FLAGS or export a frozen copy) so consumers cannot modify its properties, and ensure any code that needs to produce modifiable flags clones or spreads the frozen DEFAULT_GRANT_FLAGS before mutating.src/constants/querySource.ts-1-2 (1)
1-2:⚠️ Potential issue | 🟡 MinorDefine
QuerySourceas a proper string type rather than an empty interface.An empty interface matches any value in TypeScript's structural type system, allowing
number,boolean, or other types to be assigned where strings are expected. All usages in the codebase are string values (e.g.,'repl_main_thread','agent:builtin:${type}'). Define this astype QuerySource = string;or a union of specific valid values to restore type safety.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/constants/querySource.ts` around lines 1 - 2, The QuerySource is currently declared as an empty interface allowing any value; change it to a string-based type to enforce that only string literals are used—replace the export interface QuerySource {} with either export type QuerySource = string; or, preferably, a union of expected literal strings (e.g., 'repl_main_thread' | `agent:builtin:${string}`) to restore type safety and update any imports of QuerySource accordingly. Ensure the symbol name QuerySource remains exported so existing code compiles.src/main.tsx-976-976 (1)
976-976:⚠️ Potential issue | 🟡 MinorDocument or preserve the removed
-d2ealias to avoid silent CLI breakage.Dropping a previously accepted flag alias can break existing scripts. Please either keep a hidden deprecated alias for one release cycle or add an explicit migration note/changelog entry for
-d2e -> --debug-to-stderr.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main.tsx` at line 976, The CLI removed the short alias for --debug-to-stderr (-d2e); restore a hidden deprecated alias to avoid breaking scripts by creating a hidden Option or alias that maps '-d2e' to the existing --debug-to-stderr option (the Option created in the chain via addOption(new Option('--debug-to-stderr', ...))). Mark it hidden/deprecated (hideHelp or similar) and ensure it enables the same behavior (argParser(Boolean) and sets debug mode) so existing invocations continue to work for one release cycle.src/tools/WorkflowTool/WorkflowTool.ts-2-2 (1)
2-2:⚠️ Potential issue | 🟡 MinorAdd type annotation and consider runtime safety implications.
Exporting
nullwithout a type annotation reduces type safety. Additionally, any code that attempts to useWorkflowToolas a class, function, or object will fail at runtime. Consider either:
- Adding an explicit type annotation (e.g.,
as constor: null)- Exporting a stub class/object if consumer code expects certain methods
- Ensuring all consumers check for null before usage
🔧 Suggested type annotation
-export const WorkflowTool = null +export const WorkflowTool = null as constOr if a class is expected:
// Stub: This module was not included in the leaked source. export class WorkflowTool { // TODO: Implement when source is available }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tools/WorkflowTool/WorkflowTool.ts` at line 2, The current export export const WorkflowTool = null lacks a type and will break callers; update this by either adding a precise type annotation (e.g., export const WorkflowTool: null = null or export const WorkflowTool = null as const) or, if consumers expect methods, replace the null with a small stub (e.g., export class WorkflowTool { /* TODO: implement */ } or export const WorkflowTool = { /* stub methods */ }) and ensure any runtime usage checks for null/implements the expected API so callers won't throw.src/types/bun-bundle.d.ts-12-12 (1)
12-12:⚠️ Potential issue | 🟡 MinorFix inaccurate dev-mode behavior comment for
feature().Line 12 says it always returns
falsein development, but project docs describe env-driven flag enabling in dev. The comment should reflect that runtime shim behavior to avoid confusion.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/types/bun-bundle.d.ts` at line 12, Update the doc comment for the feature() runtime shim to remove the incorrect absolute statement that it "always returns `false`" in development and instead describe that behavior is env-driven and may be enabled in dev via a runtime shim/flag; specifically edit the comment above the feature() declaration in src/types/bun-bundle.d.ts to state that during unbundled development it typically returns false unless an environment-driven feature flag or runtime shim enables it, and mention that behavior can differ between bundled and unbundled modes.README.md-35-35 (1)
35-35:⚠️ Potential issue | 🟡 MinorUse
bun installinstead ofnpm install --legacy-peer-depsin the setup docs.Line 35 should default to Bun's native package manager for consistency with the rest of the project. The
--legacy-peer-depsflag masks peer dependency conflicts and reduces reproducibility, whereasbun installprovides deterministic resolution, speed, and a native lockfile—aligning with Bun's recommended workflow.Proposed change
- npm install --legacy-peer-deps + bun install🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.md` at line 35, Replace the npm command string "npm install --legacy-peer-deps" in the README with Bun's installer by changing that exact line to "bun install"; this updates the setup docs to use Bun's native package manager for deterministic installs and removes the legacy peer-deps flag.package.json-100-100 (1)
100-100:⚠️ Potential issue | 🟡 MinorUpdate
bun-typesto align with Bun v1.3+ requirement.The README documents Bun v1.3+ as the project's runtime, but
bun-typesis pinned to^1.2.0. This allows 1.2.x versions that lack type definitions for v1.3+ APIs. Change to^1.3.0to ensure type definitions match the minimum supported Bun version.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` at line 100, Update the bun-types dev dependency to match the project's documented Bun runtime by bumping the version specifier for "bun-types" in package.json from ^1.2.0 to ^1.3.0; find the "bun-types" entry in package.json and change its version string so type definitions include Bun v1.3+ APIs, then run your package manager install to update lockfiles.src/types/message.ts-22-22 (1)
22-22:⚠️ Potential issue | 🟡 MinorStandardize acronym casing across interface names.
SystemApiMetricsMessage(line 22) uses mixed-caseApi, whileSystemAPIErrorMessage(line 20) uses uppercaseAPI. Align the acronym casing to prevent naming inconsistencies in the codebase.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/types/message.ts` at line 22, Rename the inconsistent interface so the API acronym casing matches across types: change SystemApiMetricsMessage to SystemAPI(Metrics)Message (or rename SystemAPIErrorMessage to SystemApiErrorMessage) depending on project convention; update all references to the interface name (e.g., SystemApiMetricsMessage and SystemAPIErrorMessage) and run type-checks to ensure no usages are broken.
🧹 Nitpick comments (21)
src/tools/WebBrowserTool/WebBrowserTool.ts (1)
1-2: Prefer fail-fast stub over exportingnull.
nullplaceholders can produce opaque runtime errors downstream. Consider exporting a minimal stub that throws a clear “not implemented/missing source” error when invoked, so failures are explicit and diagnosable.Proposed stub pattern
-// Stub: This module was not included in the leaked source. -export const WebBrowserTool = null +// Stub: This module was not included in the leaked source. +export const WebBrowserTool = { + run() { + throw new Error("WebBrowserTool is unavailable: source module was not included.") + }, +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tools/WebBrowserTool/WebBrowserTool.ts` around lines 1 - 2, The current export exports WebBrowserTool as null which leads to opaque runtime errors; replace it with a fail-fast stub by exporting a minimal function or class named WebBrowserTool that immediately throws a descriptive Error (e.g., "WebBrowserTool not implemented / source missing") when instantiated or invoked, so any consumer calling WebBrowserTool fails fast and gets a clear diagnostic; update any default/named export to use this stub and ensure the thrown error includes guidance to restore the real implementation.src/components/agents/new-agent-creation/types.ts (1)
2-2: Tighten the placeholder type to avoid a silently-permissive contract.On Line 2,
export interface AgentWizardData {}is effectively too loose for a wizard payload and can let invalid shapes pass unnoticed. Prefer a stricter placeholder until real fields are known.Proposed change
-export interface AgentWizardData {} +export type AgentWizardData = Record<string, never>;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/agents/new-agent-creation/types.ts` at line 2, AgentWizardData is currently an empty interface which is too permissive; replace it with a tightened placeholder shape requiring a wizard step and a structured payload so invalid shapes can't slip through. Update the AgentWizardData declaration to require a numeric step property (e.g., step) and include an optional values property typed as a string-keyed map of unknowns (e.g., values: Record<string, unknown>) to capture arbitrary form state until real fields are defined; keep the name AgentWizardData so existing references (AgentWizardData) still resolve.src/services/skillSearch/signals.ts (1)
2-2: Use a stricter placeholder type instead of an empty interface.
export interface DiscoverySignal {}is overly permissive in TypeScript. Since this is a stub, prefer an explicitly strict placeholder to prevent accidental property assignments and catch type errors earlier.Proposed change
-export interface DiscoverySignal {} +export type DiscoverySignal = Record<string, never>;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/services/skillSearch/signals.ts` at line 2, Replace the overly permissive empty interface DiscoverySignal with a stricter placeholder type to prevent accidental property assignments; change the declaration of DiscoverySignal from "export interface DiscoverySignal {}" to a stricter type such as "export type DiscoverySignal = Record<string, never>;" (or "unknown" if you need maximal opacity), and update any code that relies on the previous interface accordingly so TypeScript will catch unintended property usage.src/tools/SleepTool/SleepTool.ts (1)
1-2: Enhance stub safety with type annotations and runtime error.While this stub is intentional, exporting
nullcan cause runtime TypeErrors if code attempts to instantiate or call methods onSleepTool. Consider adding type annotations and throwing a descriptive error to improve developer experience.🛡️ Proposed safer stub implementation
-// Stub: This module was not included in the leaked source. -export const SleepTool = null +// Stub: This module was not included in the leaked source. +export const SleepTool: null = null + +// Alternative: Throw a descriptive error if instantiated +// export class SleepTool { +// constructor() { +// throw new Error('SleepTool is not available: module was not included in leaked source') +// } +// }The type annotation
const SleepTool: nullmakes TypeScript aware this is intentionallynull, while the alternative class-based approach provides clearer runtime errors if code tries to use it before implementation.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tools/SleepTool/SleepTool.ts` around lines 1 - 2, The current export exports SleepTool as plain null which can cause confusing runtime TypeErrors; change the stub to include explicit typing and a safe runtime failure: either export SleepTool typed as null (e.g., const SleepTool: null = null) to make intent explicit to TypeScript, or replace the null export with a placeholder class named SleepTool whose constructor and any methods throw a descriptive Error like "SleepTool is a stub/not implemented" so any attempted instantiation or call surfaces a clear message; update the export to reference this typed placeholder (SleepTool) so callers get compile-time clarity and a helpful runtime error.src/tools/PushNotificationTool/PushNotificationTool.ts (1)
1-2: Consider replacing thenullexport with a fail-fast stub for better error clarity.While the current code safely guards against null-pointer errors through defensive checks (line 240 in
src/tools.ts), exporting a concrete stub that throws on usage provides clearer error messages and eliminates the need for null-checks throughout the codebase.♻️ Proposed safer stub
// Stub: This module was not included in the leaked source. -export const PushNotificationTool = null +export const PushNotificationTool = { + run() { + throw new Error("PushNotificationTool is unavailable in this source snapshot.") + }, +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tools/PushNotificationTool/PushNotificationTool.ts` around lines 1 - 2, Replace the current null export with a fail-fast stub that surfaces a clear error when used: instead of exporting PushNotificationTool = null, export a concrete stub (e.g., a class named PushNotificationTool or a factory function also named PushNotificationTool) whose constructor or call throws a descriptive Error like "PushNotificationTool is unavailable in this build; enable X to use push notifications"; update any places that import/instantiate PushNotificationTool to retain the same symbol name so imports don't change, and ensure the thrown message references the feature toggle or build configuration to guide the developer.src/utils/filePersistence/types.ts (1)
2-5: Empty interfaces provide no type safety.These empty interfaces are equivalent to
{}and will accept any object, defeating TypeScript's type checking. Consider one of these approaches:
- Add placeholder properties with
unknowntypes- Add TODO comments indicating required properties
- Use
Record<string, never>to explicitly denote intentionally empty types♻️ Example with placeholder properties
-export interface FailedPersistence {} -export interface FilesPersistedEventData {} -export interface PersistedFile {} -export interface TurnStartTime {} +// TODO: Define proper structure when implementing +export interface FailedPersistence { + // Add properties here + [key: string]: unknown +} +export interface FilesPersistedEventData { + // Add properties here + [key: string]: unknown +} +export interface PersistedFile { + // Add properties here + [key: string]: unknown +} +export interface TurnStartTime { + // Add properties here + [key: string]: unknown +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/utils/filePersistence/types.ts` around lines 2 - 5, The four empty interfaces (FailedPersistence, FilesPersistedEventData, PersistedFile, TurnStartTime) provide no type safety; replace each with a deliberate shape or explicit empty marker: either add a minimal placeholder property (e.g., _placeholder: unknown) to enforce non-empty structure, add a TODO comment above each interface describing required fields to implement later, or change the definition to Record<string, never> to indicate an intentional empty type—update all references to these interfaces accordingly so callers expect the new shape or explicit emptiness.src/types/utils.ts (1)
2-3: Replace empty interface placeholders with explicit generic type aliases.Lines 2–3 export empty interfaces that don't reflect how these types are actually used throughout the codebase. All current usages of
DeepImmutableandPermutationsinclude generic parameters (e.g.,DeepImmutable<AppState>,Permutations<PromptInputMode>). Converting to generic type aliases will be fully compatible with existing code while making the intent explicit and preventing accidental misuse.Proposed refactor
// Stub: not included in leaked source -export interface DeepImmutable {} -export interface Permutations {} +// TODO: replace with upstream implementations when available. +export type DeepImmutable<T = unknown> = T; +export type Permutations<T = unknown> = T;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/types/utils.ts` around lines 2 - 3, Replace the two empty exported interfaces DeepImmutable and Permutations with explicit generic type aliases so they reflect their actual usage (e.g., DeepImmutable<AppState>, Permutations<PromptInputMode>). Update the declarations for DeepImmutable and Permutations to be generic aliases (declare type DeepImmutable<T> = ... and type Permutations<T> = ...), preserving the semantics used across the codebase and ensuring existing generic usages remain valid; keep the exported names identical so no other files need changes and ensure the new aliases express immutability/permutation intent.src/components/Spinner/types.ts (1)
2-3: Tighten empty interface definitions to match actual usage patterns.The empty
RGBColorandSpinnerModeinterfaces do mask expected structure. The code inSpinner/utils.tsaccesses.r,.g,.bproperties onRGBColorType(parseRGB, interpolateColor, toRGBColor), andSpinnerModeis consistently used with string values (e.g.,useState<SpinnerMode>('responding')). Replace with explicit types:Proposed placeholder tightening
-export interface RGBColor {} -export interface SpinnerMode {} +export interface RGBColor { + r: number + g: number + b: number +} + +export type SpinnerMode = string🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/Spinner/types.ts` around lines 2 - 3, The empty interfaces RGBColor and SpinnerMode should be tightened to match real usage: change RGBColor (exported from types.ts) to an object type with numeric properties r, g, b to satisfy functions like parseRGB, interpolateColor, and toRGBColor in Spinner/utils.ts, and replace the empty SpinnerMode interface with a string-union type listing the actual mode values used (e.g., 'responding', 'idle', etc.) so useState<SpinnerMode>('responding') and other consumers type-check correctly; update any imports/usages to the new types accordingly.src/tools/OverflowTestTool/OverflowTestTool.ts (1)
2-2: Add a type annotation for clarity.The export lacks a type annotation, leaving the type as bare
null. While the conditional guards in usage sites (OverflowTestTool ? [...]) make the code safe at runtime, adding an explicit type annotation would clarify intent. Consider:export const OverflowTestTool: null = nullOr if this stub should eventually match the
Toolinterface fromsrc/Tool.js:export const OverflowTestTool: Tool | null = null🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tools/OverflowTestTool/OverflowTestTool.ts` at line 2, The export OverflowTestTool is declared as bare null; add an explicit type annotation to clarify intent and satisfy TypeScript consumers—either annotate it as null (OverflowTestTool: null) or, if it's a placeholder for the Tool interface, annotate as Tool | null (OverflowTestTool: Tool | null); update the export declaration for the symbol OverflowTestTool and import or reference the Tool interface/type used elsewhere so the declaration type is valid.src/cli/transports/Transport.ts (1)
2-2: Avoid an empty public transport contract.At Line 2,
interface Transport {}does not enforce meaningful structure and can hide integration mistakes. Prefer adding the minimal required members used by transport consumers.Proposed direction
-export interface Transport {} +export interface Transport { + // Define only the members currently required by call sites. + // Example: + // send(data: Uint8Array | string): Promise<void> + // close(): Promise<void> +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/cli/transports/Transport.ts` at line 2, The Transport interface is empty and should declare the minimal contract consumers rely on; update the Transport declaration to include at least a send(payload: unknown): Promise<void> method, a close(): Promise<void> method, and an isConnected(): boolean (or similarly named connection-check) so implementations like any classes referencing Transport must implement these members (search for usages of Transport in your codebase to align names/signatures with consumers).stubs/@ant/computer-use-swift/package.json (1)
1-1: Consider formatting the JSON for better readability.The minified single-line format makes the file harder to read and produces less clear git diffs when modified.
📝 Proposed formatting improvement
-{"name":"@ant/computer-use-swift","version":"0.0.0","main":"index.js","type":"module"} +{ + "name": "@ant/computer-use-swift", + "version": "0.0.0", + "main": "index.js", + "type": "module" +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stubs/`@ant/computer-use-swift/package.json at line 1, The package.json is minified into a single line which hinders readability and diffs; reformat the JSON to a human-friendly layout (pretty-print with standard 2-space indentation and trailing newline) so keys like "name", "version", "main", and "type" appear on separate lines, preserving their values from the current one-line content and committing the formatted file.src/tools/WorkflowTool/bundled/index.ts (1)
2-2: Add explicit return type annotation.The function should specify its return type as
voidfor better type safety and code clarity, even though it's a stub.🔧 Suggested enhancement
-export function initBundledWorkflows() {} +export function initBundledWorkflows(): void {}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tools/WorkflowTool/bundled/index.ts` at line 2, The exported stub function initBundledWorkflows currently lacks an explicit return type; update its declaration to include a void return type (export function initBundledWorkflows(): void {}) to improve type safety and clarity, and ensure any future returns cause a type error if unintended.stubs/anthropic-ai/sandbox-runtime/package.json (1)
1-1: Consider formatting the package.json for better readability.The package manifest is valid but condensed to a single line. Standard practice is to format package.json files with proper indentation for easier maintenance and version control.
📝 Suggested formatting
-{"name":"@anthropic-ai/sandbox-runtime","version":"0.0.0","main":"index.js","type":"module"} +{ + "name": "@anthropic-ai/sandbox-runtime", + "version": "0.0.0", + "main": "index.js", + "type": "module" +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stubs/anthropic-ai/sandbox-runtime/package.json` at line 1, The package.json for the `@anthropic-ai/sandbox-runtime` package is a single condensed line; reformat it to a standard pretty-printed JSON (e.g., 2-space indentation) so keys like "name", "version", "main", and "type" are each on their own lines for readability and cleaner diffs; update the package.json file content accordingly and commit the reformatted file.src/entrypoints/sdk/sdkUtilityTypes.ts (1)
2-2: Consider adding documentation for the stub interface.The empty
NonNullableUsageinterface serves as a placeholder. Adding JSDoc comments explaining its intended purpose would help future implementers understand what properties or methods should be added when the actual implementation is available.📋 Example documentation
// Stub: not included in leaked source +/** + * TODO: Define properties for non-nullable usage tracking/validation. + * This interface should be implemented when the actual source becomes available. + */ export interface NonNullableUsage {}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/entrypoints/sdk/sdkUtilityTypes.ts` at line 2, Add a short JSDoc block above the placeholder interface NonNullableUsage explaining that it is a stub for future non-nullable type utilities, describe the intended purpose (e.g., to collect methods/properties for converting or validating non-nullable values), include a TODO or `@internal` tag and an example of expected usage or fields that implementers should add later; update the comment in the same file next to the NonNullableUsage interface so future contributors know what to implement when this stub is expanded.src/ssh/createSSHSession.ts (1)
1-2: File naming doesn't match exported symbol.The file is named
createSSHSession.ts(suggesting a function), but it exports anSSHSessioninterface. Consider either:
- Renaming the file to
SSHSession.tsto match the export- Moving the interface to a separate file and using this file for a stub
createSSHSession()functionThis improves code discoverability and follows the convention where file names correspond to their primary export.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/ssh/createSSHSession.ts` around lines 1 - 2, The exported symbol SSHSession in createSSHSession.ts doesn't match the file name; either rename the file to SSHSession.ts to reflect the interface export, or move the SSHSession interface into a new SSHSession.ts and implement a stub createSSHSession() function in createSSHSession.ts (exporting createSSHSession) so the file name corresponds to its primary export; update any imports that reference SSHSession or createSSHSession accordingly.src/ink/global.d.ts (1)
1-1: Consider removing or documenting the purpose of this empty declaration file.This file contains only a stub comment with no TypeScript declarations. Empty
.d.tsfiles provide no type information and may create confusion about what global declarations are expected here. If the file is necessary for build tooling or future implementation, consider adding a TODO comment explaining what declarations should eventually be added.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/ink/global.d.ts` at line 1, The empty declaration stub in src/ink/global.d.ts should either be removed or documented: if the file is not required, delete src/ink/global.d.ts; otherwise add a short TODO comment explaining its purpose (e.g., intended global types or build-tool requirement) and optionally stub an exported declaration like an example global interface so future contributors know what belongs here; reference the file name global.d.ts when making the change.src/ssh/SSHSessionManager.ts (1)
2-2: Consider adding documentation for future implementation.The empty
SSHSessionManagerinterface serves as a placeholder. Adding JSDoc comments describing the expected responsibilities of an SSH session manager would guide future implementation.📋 Example documentation
// Stub: not included in leaked source +/** + * TODO: Interface for managing SSH session lifecycle. + * Should handle session creation, tracking, and cleanup when implemented. + */ export interface SSHSessionManager {}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/ssh/SSHSessionManager.ts` at line 2, Add a JSDoc block above the SSHSessionManager interface that documents its intended responsibilities and expected surface (e.g., lifecycle management of SSH connections, methods for connect/disconnect/executeCommand/forwardPort, error-handling and resource cleanup expectations), so future implementers know what methods and behavior to provide when filling in the placeholder SSHSessionManager interface; reference the SSHSessionManager symbol in the comment and list the key responsibilities and example method signatures (without implementation) to guide future additions.src/tools/CtxInspectTool/CtxInspectTool.ts (1)
2-2: Add type annotation for better type safety.The
nullexport should have an explicit type annotation to improve type checking. Additionally, ensure consuming code handles the null value appropriately to prevent runtime errors.🔧 Suggested type annotation
-export const CtxInspectTool = null +export const CtxInspectTool = null as const🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tools/CtxInspectTool/CtxInspectTool.ts` at line 2, The export CtxInspectTool is currently set to null without a type; add an explicit type annotation (e.g., a CtxInspectTool type or interface name) so it reads as CtxInspectTool: YourToolType | null = null to improve type safety and signal consumers to handle the nullable case; update or create the corresponding type/interface (e.g., CtxInspectToolType or ICtxInspectTool) and ensure all usages of CtxInspectTool check for null before invoking methods or accessing properties.stubs/@ant/computer-use-input/package.json (1)
1-1: Consider formatting for readability.The minified JSON is valid but harder to maintain. Consider formatting it for better readability.
📝 Formatted version for readability
-{"name":"@ant/computer-use-input","version":"0.0.0","main":"index.js","type":"module"} +{ + "name": "@ant/computer-use-input", + "version": "0.0.0", + "main": "index.js", + "type": "module" +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stubs/`@ant/computer-use-input/package.json at line 1, The package.json currently is a single-line/minified JSON string; reformat it to a pretty-printed, multi-line JSON object for readability by updating the file to include each top-level field on its own line (e.g., "name", "version", "main", "type") with proper indentation and trailing newline; ensure valid JSON syntax is preserved and fields like "name":"@ant/computer-use-input", "version":"0.0.0", "main":"index.js", and "type":"module" remain unchanged.src/components/mcp/types.ts (1)
2-8: Use typed objects instead of empty interfaces to enforce shape constraints.Lines 2–8 currently define empty interfaces that accept any non-null value without enforcing property shape. The active usage patterns (e.g., assigning
{ name, client, ... }objects) show these should have defined structure. Use constrained type aliases instead:Recommended approach
+type ServerInfoBase = Record<string, unknown> -export interface AgentMcpServerInfo {} -export interface ClaudeAIServerInfo {} -export interface HTTPServerInfo {} -export interface MCPViewState {} -export interface SSEServerInfo {} -export interface ServerInfo {} -export interface StdioServerInfo {} +export type AgentMcpServerInfo = ServerInfoBase +export type ClaudeAIServerInfo = ServerInfoBase +export type HTTPServerInfo = ServerInfoBase +export type MCPViewState = ServerInfoBase +export type SSEServerInfo = ServerInfoBase +export type ServerInfo = ServerInfoBase +export type StdioServerInfo = ServerInfoBaseAlternatively, define explicit shapes for each once the stub source is available.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/mcp/types.ts` around lines 2 - 8, The empty interfaces (AgentMcpServerInfo, ClaudeAIServerInfo, HTTPServerInfo, MCPViewState, SSEServerInfo, ServerInfo, StdioServerInfo) accept any non-null value; replace them with concrete typed object shapes (or constrained type aliases) that reflect actual usage — e.g., include properties seen when these objects are constructed/consumed such as name, client, url/port, process/stdio handles, and any view/state fields — or explicitly declare minimal required fields if full shapes are unknown; update each interface declaration to a typed alias or interface with those required properties (keeping names AgentMcpServerInfo, ClaudeAIServerInfo, HTTPServerInfo, MCPViewState, SSEServerInfo, ServerInfo, StdioServerInfo) so callers get proper compile-time shape checks.plugins/bunBundleDev.ts (1)
16-18: Normalize feature flag tokens before Set insertion.At Line 17, whitespace is not trimmed, so
FEATURE_FLAGS=KAIROS, VOICE_MODEwon’t matchVOICE_MODE.💡 Proposed fix
const enabledFlags = new Set( - (process.env.FEATURE_FLAGS ?? '').split(',').filter(Boolean), + (process.env.FEATURE_FLAGS ?? '') + .split(',') + .map((flag) => flag.trim()) + .filter(Boolean), )🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/bunBundleDev.ts` around lines 16 - 18, The feature-flag tokens are not normalized before being stored in enabledFlags, so values like " VOICE_MODE" won't match; update the initialization of enabledFlags to split process.env.FEATURE_FLAGS, then map each token through .trim() (and optionally .toUpperCase() if flags are case-insensitive), filter out empty strings, and then create the Set from those normalized tokens (reference: enabledFlags and process.env.FEATURE_FLAGS).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2c73cc1e-05ac-4f6d-a814-965b5e32f280
📒 Files selected for processing (113)
.gitignoreREADME.mdbunfig.tomlpackage.jsonplugins/bunBundleDev.tssrc/assistant/sessionDiscovery.tssrc/cli/transports/Transport.tssrc/commands/install-github-app/types.tssrc/commands/plugin/types.tssrc/commands/plugin/unifiedTypes.tssrc/components/FeedbackSurvey/utils.tssrc/components/Spinner/types.tssrc/components/agents/new-agent-creation/types.tssrc/components/mcp/types.tssrc/components/ui/option.tssrc/components/wizard/types.tssrc/constants/querySource.tssrc/entrypoints/sdk/controlTypes.tssrc/entrypoints/sdk/coreTypes.generated.tssrc/entrypoints/sdk/runtimeTypes.tssrc/entrypoints/sdk/sdkUtilityTypes.tssrc/entrypoints/sdk/settingsTypes.generated.tssrc/entrypoints/sdk/toolTypes.tssrc/ink/cursor.tssrc/ink/events/paste-event.tssrc/ink/events/resize-event.tssrc/ink/global.d.tssrc/keybindings/types.tssrc/main.tsxsrc/query/transitions.tssrc/services/lsp/types.tssrc/services/oauth/types.tssrc/services/skillSearch/signals.tssrc/services/tips/types.tssrc/skills/bundled/claude-api/SKILL.md.tssrc/skills/bundled/claude-api/csharp/claude-api.md.tssrc/skills/bundled/claude-api/curl/examples.md.tssrc/skills/bundled/claude-api/go/claude-api.md.tssrc/skills/bundled/claude-api/java/claude-api.md.tssrc/skills/bundled/claude-api/php/claude-api.md.tssrc/skills/bundled/claude-api/python/agent-sdk/README.md.tssrc/skills/bundled/claude-api/python/agent-sdk/patterns.md.tssrc/skills/bundled/claude-api/python/claude-api/README.md.tssrc/skills/bundled/claude-api/python/claude-api/batches.md.tssrc/skills/bundled/claude-api/python/claude-api/files-api.md.tssrc/skills/bundled/claude-api/python/claude-api/streaming.md.tssrc/skills/bundled/claude-api/python/claude-api/tool-use.md.tssrc/skills/bundled/claude-api/ruby/claude-api.md.tssrc/skills/bundled/claude-api/shared/error-codes.md.tssrc/skills/bundled/claude-api/shared/live-sources.md.tssrc/skills/bundled/claude-api/shared/models.md.tssrc/skills/bundled/claude-api/shared/prompt-caching.md.tssrc/skills/bundled/claude-api/shared/tool-use-concepts.md.tssrc/skills/bundled/claude-api/typescript/agent-sdk/README.md.tssrc/skills/bundled/claude-api/typescript/agent-sdk/patterns.md.tssrc/skills/bundled/claude-api/typescript/claude-api/README.md.tssrc/skills/bundled/claude-api/typescript/claude-api/batches.md.tssrc/skills/bundled/claude-api/typescript/claude-api/files-api.md.tssrc/skills/bundled/claude-api/typescript/claude-api/streaming.md.tssrc/skills/bundled/claude-api/typescript/claude-api/tool-use.md.tssrc/skills/bundled/verify/SKILL.md.tssrc/skills/bundled/verify/examples/cli.md.tssrc/skills/bundled/verify/examples/server.md.tssrc/ssh/SSHSessionManager.tssrc/ssh/createSSHSession.tssrc/tasks/LocalWorkflowTask/LocalWorkflowTask.tssrc/tasks/MonitorMcpTask/MonitorMcpTask.tssrc/tools/CtxInspectTool/CtxInspectTool.tssrc/tools/ListPeersTool/ListPeersTool.tssrc/tools/MonitorTool/MonitorTool.tssrc/tools/OverflowTestTool/OverflowTestTool.tssrc/tools/PushNotificationTool/PushNotificationTool.tssrc/tools/REPLTool/REPLTool.tssrc/tools/SendUserFileTool/SendUserFileTool.tssrc/tools/SleepTool/SleepTool.tssrc/tools/SnipTool/SnipTool.tssrc/tools/SubscribePRTool/SubscribePRTool.tssrc/tools/SuggestBackgroundPRTool/SuggestBackgroundPRTool.tssrc/tools/TerminalCaptureTool/TerminalCaptureTool.tssrc/tools/TungstenTool/TungstenLiveMonitor.tssrc/tools/TungstenTool/TungstenTool.tssrc/tools/VerifyPlanExecutionTool/VerifyPlanExecutionTool.tssrc/tools/WebBrowserTool/WebBrowserTool.tssrc/tools/WorkflowTool/WorkflowTool.tssrc/tools/WorkflowTool/bundled/index.tssrc/tools/WorkflowTool/constants.tssrc/types/bun-bundle.d.tssrc/types/connectorText.tssrc/types/fileSuggestion.tssrc/types/macro.d.tssrc/types/message.tssrc/types/messageQueueTypes.tssrc/types/notebook.tssrc/types/statusLine.tssrc/types/tools.tssrc/types/utils.tssrc/utils/filePersistence/types.tssrc/utils/secureStorage/types.tsstubs/@ant/claude-for-chrome-mcp/index.jsstubs/@ant/claude-for-chrome-mcp/package.jsonstubs/@ant/computer-use-input/index.jsstubs/@ant/computer-use-input/package.jsonstubs/@ant/computer-use-mcp/index.jsstubs/@ant/computer-use-mcp/package.jsonstubs/@ant/computer-use-mcp/sentinelApps.jsstubs/@ant/computer-use-mcp/types.jsstubs/@ant/computer-use-swift/index.jsstubs/@ant/computer-use-swift/package.jsonstubs/@anthropic-ai/mcpb/index.jsstubs/@anthropic-ai/mcpb/package.jsonstubs/anthropic-ai/sandbox-runtime/index.jsstubs/anthropic-ai/sandbox-runtime/package.jsontsconfig.json
| "react": "^19.3.0-canary-705268dc-20260409", | ||
| "react-compiler-runtime": "^1.0.0", | ||
| "react-reconciler": "^0.34.0-canary-705268dc-20260409", | ||
| "semver": "^7.6.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What @types/reactand@types/react-reconciler` versions are compatible with:
- react@19.3.0-canary-705268dc-20260409
- react-reconciler@0.34.0-canary-705268dc-20260409
?`
💡 Result:
The compatible versions are the latest @types/react (19.2.14) and @types/react-reconciler (0.33.0). These provide types for React 19, including ongoing canary updates via the react/canary.d.ts augmentation in DefinitelyTyped. No specific canary-tagged @types packages exist; types are maintained to support current and experimental React 19 features as evidenced by recent commits adding canary-specific types like SubmitEvent.submitter and optimisticKey.
Citations:
- 1: [react] Types for React 19 DefinitelyTyped/DefinitelyTyped#69022
- 2: https://npmx.dev/package/@types/react/v/%5E18.0.0||%5E19.0.0
- 3: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react-reconciler/index.d.ts
- 4: https://www.npmjs.com/package/@types/react-reconciler
- 5: https://www.npmjs.com/package/@types/react-reconciler?activeTab=dependents
- 6: https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/react
- 7: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/canary.d.ts
- 8: https://www.npmjs.com/package/@types/react?activeTab=versions
🏁 Script executed:
sed -n '94,96p' package.jsonRepository: tanbiralam/claude-code
Length of output: 169
Update @types/react and @types/react-reconciler versions to match React runtime.
The canary runtime versions (React 19 and react-reconciler 0.34) are paired with mismatched type packages: @types/react@^18.3.0 targets React 18, and @types/react-reconciler@^0.28.0 is outdated. Update to @types/react@^19.2.14 and @types/react-reconciler@^0.33.0 to resolve incompatibilities and prevent typecheck failures.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` around lines 66 - 69, Update the type package versions in
package.json so they match the canary React runtime: change the `@types/react`
entry (currently ^18.3.0) to ^19.2.14 and change `@types/react-reconciler`
(currently ^0.28.0) to ^0.33.0; modify the dependency entries for "@types/react"
and "@types/react-reconciler" in package.json, run install, and re-run the
typecheck to confirm the mismatch is resolved.
| "wrap-ansi": "^9.0.0", | ||
| "ws": "^8.18.0", | ||
| "xss": "^1.0.15", | ||
| "zod": "^3.24.0" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the current stable Zod v4 release, and which APIs differ from Zod v3 that could break existing TypeScript code?
💡 Result:
The current stable release of Zod v4 is 4.3.6, released on January 22, 2026. Key APIs that differ from Zod v3 and could break existing TypeScript code include: Error customization: Deprecated message parameter in favor of unified error parameter (function). Dropped invalid_type_error and required_error parameters. errorMap is dropped. ZodError changes: Updated issue formats (streamlined, some merged/dropped like ZodNotFiniteIssue). Deprecated .format, .flatten, .formErrors. Deprecated .addIssue and .addIssues. z.number: No longer accepts infinite values (Infinity/-Infinity). .safe no longer accepts floats (behaves like .int). .int accepts only safe integers. z.string: Deprecated chained methods like .email, .uuid etc. (now top-level z.email, z.uuid). Stricter .uuid validation. .refine: Ignores type predicates. Drops ctx.path. Drops function as second argument. Optional helpers dropped: z.ostring, z.onumber, etc. z.literal: Drops symbol support. z.record: Drops single argument usage. Improved enum support (exhaustive checking). z.intersection: Throws regular Error on merge conflict (instead of ZodError). z.tuple: NonEmptyTuple now infers string[] instead of [string, ...string[]]. z.coerce: Input type now unknown instead of specific types. z.promise: Deprecated. Internal: Generic updates, ._def moved to ._zod.def, ZodEffects split, etc. These affect type inference and advanced usage. Requires TypeScript strict mode and TS 5.5+. A codemod npx @zod/codemod --transform v3-to-v4 handles many changes. Official migration guide: https://zod.dev/v4/changelog
Citations:
- 1: https://zod.dev/v4
- 2: https://github.com/colinhacks/zod/releases
- 3: https://www.npmjs.com/package/zod?activeTab=versions
- 4: https://zod.dev/v4/changelog
- 5: https://www.npmjs.com/package/zod/v/4.3.6
- 6: https://github.com/colinhacks/zod/releases/tag/v4.3.6
- 7: https://github.com/colinhacks/zod/blob/c7805073/packages/docs/content/v4/changelog.mdx
- 8: https://www.npmjs.com/package/zod
🏁 Script executed:
# Find and check documentation files for Zod version references
find . -type f \( -name "README*" -o -name "*.md" -o -name "CHANGELOG*" \) -exec grep -l "zod\|Zod" {} \; 2>/dev/null | head -20Repository: tanbiralam/claude-code
Length of output: 77
🏁 Script executed:
# Search for Zod usage in the codebase to detect v4-specific APIs
rg "z\.(email|uuid|string|number|refine|promise)" --type ts --type tsx --type js --type jsx -c 2>/dev/null | head -30Repository: tanbiralam/claude-code
Length of output: 48
🏁 Script executed:
# Check tsconfig for TypeScript version requirement (v4 needs 5.5+)
cat -n tsconfig.json 2>/dev/null || echo "No tsconfig.json found"Repository: tanbiralam/claude-code
Length of output: 995
🏁 Script executed:
# Check if there are any v4 migration references or comments in the codebase
rg "v4|migration|zod.*4" --type ts --type tsx --type js --type jsx -i -c 2>/dev/null | head -20Repository: tanbiralam/claude-code
Length of output: 48
🏁 Script executed:
# Read README.md to see what it says about Zod
cat README.mdRepository: tanbiralam/claude-code
Length of output: 11243
🏁 Script executed:
# Search for Zod imports to see how it's actually used
rg "import.*zod|from.*zod|require.*zod" --type ts --type tsx --type js --type jsxRepository: tanbiralam/claude-code
Length of output: 93
🏁 Script executed:
# Check actual dependencies in package.json around the zod line
sed -n '80,95p' package.jsonRepository: tanbiralam/claude-code
Length of output: 552
🏁 Script executed:
# Check the schemas directory to see actual Zod usage patterns
find src/schemas -type f -name "*.ts" -o -name "*.tsx" | head -5Repository: tanbiralam/claude-code
Length of output: 86
🏁 Script executed:
# Look at one schema file to see what Zod APIs are being used
ls -la src/schemas/ 2>/dev/null | head -20Repository: tanbiralam/claude-code
Length of output: 237
🏁 Script executed:
cat src/schemas/hooks.tsRepository: tanbiralam/claude-code
Length of output: 7947
Zod version mismatch is a runtime blocker.
package.json pins v3.24.0, but the codebase imports from zod/v4 (e.g., line 10 in src/schemas/hooks.ts). The v4 entry point does not exist in v3 and will cause a MODULE_NOT_FOUND error at build or startup. README correctly documents Zod v4 as the intended dependency.
Update package.json to "zod": "^4.0.0" or higher (stable is 4.3.6). Verify TypeScript 5.5+ compatibility after upgrading.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` at line 85, The package.json currently pins "zod": "^3.24.0"
which conflicts with imports from "zod/v4" (e.g., imports in
src/schemas/hooks.ts) and will cause MODULE_NOT_FOUND; update the dependency in
package.json to a Zod v4 release (e.g., "zod": "^4.3.6" or at least "^4.0.0"),
run npm/yarn install and rebuild, and verify TypeScript compatibility (TS 5.5+)
before committing so imports like "zod/v4" resolve correctly.
| @@ -0,0 +1,2 @@ | |||
| // Stub: not included in leaked source | |||
| export interface Cursor {} | |||
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In current TypeScript, what values are assignable to an empty interface like interface Cursor {} and what stricter placeholder type is recommended for “no properties allowed”?
💡 Result:
In current TypeScript (as of 2026), an empty interface interface Cursor {} is equivalent to the type {}, which accepts any non-nullish value (primitives like strings/numbers/booleans, objects, arrays, functions, etc.) due to structural typing. Only null and undefined are not assignable (with strictNullChecks on). The stricter placeholder type recommended for "no properties allowed" (only accepting {} the empty object literal, rejecting anything with properties or primitives) is Record<string, never> (or equivalently { [key: string]: never }). Example: type StrictEmpty = Record<string, never>; const valid: StrictEmpty = {}; // OK const invalid1: StrictEmpty = { foo: 1 }; // Error: Type 'number' is not assignable to 'never' const invalid2: StrictEmpty = "string"; // Error: Type 'string' is not assignable to 'Record<string, never>' This is widely recommended by linters like typescript-eslint (no-empty-object-type) and community sources to avoid the pitfalls of {}.
Citations:
- 1: https://ts.coach/learn/objects/interfaces/empty/
- 2: https://stackoverflow.com/questions/78461860/why-an-empty-object-can-the-type-asserted-to-anything
- 3: https://typescript-eslint.io/rules/no-empty-object-type/
- 4: https://stackoverflow.com/questions/60111963/define-an-empty-object-type-in-typescript
- 5: https://typescript-eslint.io/rules/no-empty-interface/
- 6: https://www.totaltypescript.com/the-empty-object-type-in-typescript
🏁 Script executed:
# Check if the file exists and read its content
if [ -f "src/ink/cursor.ts" ]; then
echo "=== File content (with line numbers) ==="
cat -n "src/ink/cursor.ts"
else
echo "File not found at src/ink/cursor.ts"
# Try to locate the file
echo "=== Searching for cursor.ts files ==="
find . -name "cursor.ts" -type f 2>/dev/null | head -20
fiRepository: tanbiralam/claude-code
Length of output: 186
🏁 Script executed:
# Search for usages of Cursor type
echo "=== Searching for 'Cursor' type usages ==="
rg "Cursor" --type ts --type tsx -B 2 -A 2 | head -100Repository: tanbiralam/claude-code
Length of output: 153
🏁 Script executed:
# Search for usages of Cursor type without tsx flag
echo "=== Searching for 'Cursor' usages in TypeScript files ==="
rg "Cursor" --type ts -B 2 -A 2
echo ""
echo "=== Alternative: grep for Cursor imports/exports ==="
rg "from.*cursor|import.*Cursor|export.*Cursor" --type tsRepository: tanbiralam/claude-code
Length of output: 50379
🏁 Script executed:
# Search specifically for imports from ink/cursor or references to the stub interface
echo "=== Searching for imports from 'ink/cursor' ==="
rg "from.*ink/cursor|import.*from.*cursor" --type ts | grep -v "utils/Cursor"
echo ""
echo "=== Checking src/ink directory structure ==="
find src/ink -type f -name "*.ts" | head -20
echo ""
echo "=== Checking if cursor is exported from ink's main exports ==="
rg "export.*Cursor|export.*cursor" src/ink --type ts | head -20Repository: tanbiralam/claude-code
Length of output: 2552
🏁 Script executed:
# Check how Cursor is used in frame.ts
echo "=== Cursor usage in src/ink/frame.ts ==="
cat -n src/ink/frame.ts | head -100Repository: tanbiralam/claude-code
Length of output: 4198
🏁 Script executed:
# Search for all places where cursor object is created or assigned
echo "=== All assignments to cursor in src/ink/frame.ts ==="
rg "cursor.*:" src/ink/frame.ts -A 1 | head -50
echo ""
echo "=== Check if there are other usages of the Cursor type ==="
rg "Frame\[|\.cursor" src/ink --type ts -B 1 -A 1 | head -100Repository: tanbiralam/claude-code
Length of output: 5718
Specify the actual Cursor shape instead of using an empty interface placeholder.
Cursor {} is too permissive as a contract. The actual implementation uses objects with { x: number; y: number; visible: boolean } properties (as seen in frame.ts and log-update.ts), so define the interface to match:
export interface Cursor {
x: number
y: number
visible: boolean
}
Note: Record<string, never> would reject these properties and cause type errors, so avoid that approach.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/ink/cursor.ts` at line 2, The Cursor interface is currently an empty
placeholder; update the export interface Cursor to match the actual shape used
elsewhere (e.g., frame.ts and log-update.ts) by defining the three properties:
x: number, y: number, and visible: boolean so consumers of Cursor have the
correct type contract.
| @@ -0,0 +1,2 @@ | |||
| // Stub: This module was not included in the leaked source. | |||
| export const SubscribePRTool = null | |||
There was a problem hiding this comment.
Avoid exporting null for a runtime tool contract.
null here can cause runtime crashes when the tool is consumed. Prefer an explicit stub implementation that throws a clear “not available in leaked source” error on use.
Suggested safer stub
-export const SubscribePRTool = null
+export const SubscribePRTool = {
+ execute() {
+ throw new Error('SubscribePRTool is unavailable in this source snapshot.')
+ },
+}📝 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.
| export const SubscribePRTool = null | |
| export const SubscribePRTool = { | |
| execute() { | |
| throw new Error('SubscribePRTool is unavailable in this source snapshot.') | |
| }, | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/tools/SubscribePRTool/SubscribePRTool.ts` at line 2, The export
SubscribePRTool is set to null which can crash consumers at runtime; replace
this with an explicit stub implementation named SubscribePRTool that preserves
the original tool contract (e.g., same exported type/shape) but throws a clear,
descriptive Error like "SubscribePRTool not available in leaked source" when any
of its runtime methods (or its default call) are invoked; update the exported
symbol SubscribePRTool so imports still succeed but any use fails fast with that
clear message.
| @@ -0,0 +1,2 @@ | |||
| // Stub: This module was not included in the leaked source. | |||
| export const TerminalCaptureTool = null | |||
There was a problem hiding this comment.
Don’t export null for a tool entrypoint.
At Line 2, null can trigger downstream runtime crashes (TypeError) in registries/callers expecting a tool object. Export a fail-fast stub with an explicit error instead.
Safer stub pattern
-export const TerminalCaptureTool = null
+export const TerminalCaptureTool = {
+ name: 'TerminalCaptureTool',
+ run: async () => {
+ throw new Error('TerminalCaptureTool is unavailable in this source distribution.')
+ },
+}📝 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.
| export const TerminalCaptureTool = null | |
| export const TerminalCaptureTool = { | |
| name: 'TerminalCaptureTool', | |
| run: async () => { | |
| throw new Error('TerminalCaptureTool is unavailable in this source distribution.') | |
| }, | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/tools/TerminalCaptureTool/TerminalCaptureTool.ts` at line 2, Currently
TerminalCaptureTool is exported as null which can cause TypeErrors for
consumers; replace the null export with a fail-fast stub (e.g., an object or
function named TerminalCaptureTool) that preserves the expected shape
(name/methods used by callers, such as run/execute or init) and immediately
throws a descriptive Error when invoked (e.g., "TerminalCaptureTool not
implemented" or "TerminalCaptureTool stub: not available in this build"). Ensure
the exported symbol remains TerminalCaptureTool and implements the same
interface (method names) callers expect so runtime code fails fast with a clear
message instead of causing null dereference errors.
| @@ -0,0 +1 @@ | |||
| export function getSentinelCategory() { return null; } | |||
There was a problem hiding this comment.
Fail fast instead of silently returning null in this exported stub.
At Line 1, unconditional null can hide missing implementation and cause ambiguous downstream behavior. Throwing an explicit stub error is safer.
Suggested change
-export function getSentinelCategory() { return null; }
+export function getSentinelCategory() {
+ throw new Error("Stub not implemented: getSentinelCategory");
+}📝 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.
| export function getSentinelCategory() { return null; } | |
| export function getSentinelCategory() { | |
| throw new Error("Stub not implemented: getSentinelCategory"); | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@stubs/`@ant/computer-use-mcp/sentinelApps.js at line 1, The exported stub
getSentinelCategory currently returns null silently which can mask missing
implementations; replace the unconditional null return with a thrown explicit
Error (e.g., "getSentinelCategory not implemented" or similar) so callers fail
fast; update the exported function getSentinelCategory to throw that descriptive
error instead of returning null to make missing implementation obvious at
runtime.
| @@ -0,0 +1,3 @@ | |||
| export async function mcpbRun() { return null; } | |||
| export async function mcpbInstall() { return null; } | |||
| export function validateManifest() { return true; } | |||
There was a problem hiding this comment.
Do not hardcode manifest validation to success.
Line 3 makes validation always pass, which is a fail-open behavior and can hide invalid or unsafe manifests.
Safer stub behavior
-export function validateManifest() { return true; }
+export function validateManifest() {
+ throw new Error("@anthropic-ai/mcpb stub: validateManifest is not implemented");
+}📝 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.
| export function validateManifest() { return true; } | |
| export function validateManifest() { | |
| throw new Error("@anthropic-ai/mcpb stub: validateManifest is not implemented"); | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@stubs/`@anthropic-ai/mcpb/index.js at line 3, The stub validateManifest
currently always returns true which hides invalid manifests; change
validateManifest to accept a manifest input and perform real structural
validation (e.g., check it is an object and contains required fields/types or
validate against a JSON schema) and then return true only for valid manifests or
throw/return false for invalid ones; update the function named validateManifest
in the stub to validate input instead of hardcoding success and include clear
error messages or error throws when validation fails.
| @@ -0,0 +1 @@ | |||
| {"name":"@anthropic-ai/mcpb","version":"0.0.0","main":"index.js","type":"module"} | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Stub exports in stubs/@anthropic-ai/mcpb/index.js =="
cat stubs/@anthropic-ai/mcpb/index.js
echo
echo "== Imports from `@anthropic-ai/mcpb` across repo =="
rg -n -C2 "from '@anthropic-ai/mcpb'|import\('@anthropic-ai/mcpb'\)"
echo
echo "== Direct symbol usage for expected exports =="
rg -n -C2 '\b(getMcpConfigForManifest|McpbManifestSchema)\b'Repository: tanbiralam/claude-code
Length of output: 2622
Stub package missing required exports for production code.
The stub's entry point only exports mcpbRun, mcpbInstall, and validateManifest. However, production code imports McpbManifest, McpbUserConfigurationOption (types), getMcpConfigForManifest, and McpbManifestSchema from this package. Runtime failures will occur when these imports are evaluated.
| export class SandboxManager { | ||
| constructor() {} | ||
| start() { return Promise.resolve(); } | ||
| stop() { return Promise.resolve(); } | ||
| } | ||
| export const SandboxRuntimeConfigSchema = {}; | ||
| export class SandboxViolationStore { | ||
| constructor() {} | ||
| getViolations() { return []; } | ||
| } |
There was a problem hiding this comment.
Fail-open sandbox stub is unsafe; fail fast instead.
These no-op methods can make callers assume sandbox protections are active when they are not. For isolation/security code, stubs should throw immediately.
Fail-closed stub pattern
export class SandboxManager {
- constructor() {}
- start() { return Promise.resolve(); }
- stop() { return Promise.resolve(); }
+ constructor() {
+ throw new Error("@anthropic-ai/sandbox-runtime stub is non-functional");
+ }
+ start() {
+ throw new Error("@anthropic-ai/sandbox-runtime stub is non-functional");
+ }
+ stop() {
+ throw new Error("@anthropic-ai/sandbox-runtime stub is non-functional");
+ }
}
export const SandboxRuntimeConfigSchema = {};
export class SandboxViolationStore {
- constructor() {}
- getViolations() { return []; }
+ constructor() {
+ throw new Error("@anthropic-ai/sandbox-runtime stub is non-functional");
+ }
+ getViolations() {
+ throw new Error("@anthropic-ai/sandbox-runtime stub is non-functional");
+ }
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@stubs/anthropic-ai/sandbox-runtime/index.js` around lines 2 - 11, The current
sandbox stub (SandboxManager, SandboxViolationStore, SandboxRuntimeConfigSchema)
silently succeeds and returns empty results which is unsafe; change the stub to
fail-fast by having SandboxManager constructor or its start/stop methods throw a
clear, descriptive error (e.g., "Sandbox runtime not implemented/disabled")
instead of resolving, and have SandboxViolationStore.getViolations throw the
same error; keep SandboxRuntimeConfigSchema exported but ensure callers cannot
assume an actual sandbox is active because any attempt to use SandboxManager or
SandboxViolationStore will immediately throw.
| "allowImportingTsExtensions": true, | ||
| "noEmit": true | ||
| }, | ||
| "include": ["src/**/*.ts", "src/**/*.tsx"], |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python - <<'PY'
import json
from pathlib import Path, PurePosixPath
cfg = json.loads(Path("tsconfig.json").read_text())
includes = cfg.get("include", [])
excludes = cfg.get("exclude", [])
def is_included(p: str) -> bool:
pp = PurePosixPath(p)
return any(pp.match(pattern) for pattern in includes)
def is_excluded(p: str) -> bool:
pp = PurePosixPath(p)
for pattern in excludes:
if pp.match(pattern):
return True
if p.startswith(pattern.rstrip("/") + "/"):
return True
return False
ts_files = [
f.as_posix() for f in Path(".").rglob("*")
if f.suffix in (".ts", ".tsx")
]
uncovered = [p for p in ts_files if not is_excluded(p) and not is_included(p)]
print("Uncovered TS/TSX files:")
for p in sorted(uncovered):
print("-", p)
PYRepository: tanbiralam/claude-code
Length of output: 50378
🏁 Script executed:
# Check if plugins/bunBundleDev.ts exists and examine plugins directory
find plugins -name "*.ts" -o -name "*.tsx" 2>/dev/null | sort
# Also check the actual tsconfig.json to see all relevant configuration
cat tsconfig.jsonRepository: tanbiralam/claude-code
Length of output: 816
Include plugins/ in tsconfig.json type-checking.
The include patterns only cover src/**, leaving plugin TypeScript files uncovered. plugins/bunBundleDev.ts is not type-checked by this configuration.
Proposed fix
- "include": ["src/**/*.ts", "src/**/*.tsx"],
+ "include": ["src/**/*.ts", "src/**/*.tsx", "plugins/**/*.ts"],📝 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.
| "include": ["src/**/*.ts", "src/**/*.tsx"], | |
| "include": ["src/**/*.ts", "src/**/*.tsx", "plugins/**/*.ts"], |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@tsconfig.json` at line 27, The tsconfig.json "include" currently only covers
"src/**/*.ts" and "src/**/*.tsx", so TypeScript files under plugins (e.g.,
plugins/bunBundleDev.ts) aren't type-checked; update the "include" array in
tsconfig.json to add a pattern for plugin files (for example "plugins/**/*.ts"
and/or "plugins/**/*.tsx") so files like plugins/bunBundleDev.ts are included in
the project type-checking.
|
@tanbiralam merge this |
Summary by CodeRabbit
New Features
Chores
Bug Fixes