The profile command is imported and registered but the implementation file src/commands/profile.ts is missing. This will cause a runtime error when the CLI is executed. The command needs to be either implemented or removed from the imports and command registration.

The profile command is registered but the implementation file src/commands/profile.ts is missing. This command registration should be removed or the implementation should be added to prevent runtime errors.

seems like a good recommendation

The logic for filtering files starting with '.realm.json' is incorrect. The condition !filename.startsWith('.realm.json') will skip '.realm.json' files, which contradicts the intention shown in lines 52 and 143 where '.realm.json' should be included. This should be && filename !== '.realm.json' to match the pattern used elsewhere in the code.

The stop command uses Unix-specific shell commands ('ps aux', 'grep') which will fail on Windows. This command should either detect the platform and use appropriate commands (e.g., tasklist/taskkill on Windows) or document that it only works on Unix-like systems. Additionally, the regex pattern assumes 'tsx' is in the command, but when installed globally with 'npm install -g', the process name will be 'boxel' or 'node', not 'tsx'.

The help text documents extensive profile command usage (lines 384-388), but the profile command implementation is missing. This will confuse users who try to follow the documented examples. These examples should either be removed or the profile command implementation should be added.

The example boxel profile add -u @user:boxel.ai -p "pass" -n "Prod" encourages passing real passwords directly on the command line, which exposes credentials to other local users via process listings, shell history, and orchestration logs. An attacker with local access can capture the password by inspecting running processes or historic commands and then log into the Boxel account. Prefer documenting the interactive profile add flow or environment-based configuration for real usage, and clearly warn against supplying real passwords via the -p flag in CLI examples.

seems like a good recommendation

These non-interactive examples (npm run dev -- profile add -u @username:boxel.ai -p "password" -n ...) promote passing real passwords as CLI arguments, which can leak credentials via process lists, shell history, and CI/CD or container orchestration metadata. A local attacker (or anyone with access to process metadata/logs) could capture these passwords and reuse them to authenticate to Boxel. Recommend emphasizing the interactive profile add flow for humans and more secure secret injection mechanisms (env vars, secret stores) for automation, and explicitly warning against using -p with real passwords in scripts.

The boxel profile add -u @user:boxel.ai -p pass -n "Name" example teaches users to provide passwords on the command line, which is insecure because arguments are visible to other local users via ps, shell history, and some logging systems. An attacker with access to the same host could harvest these credentials and log into the associated Boxel account. Update the docs to recommend the interactive profile add flow for entering passwords and reserve any non-interactive usage for safer secret mechanisms instead of -p.

seems like a good recommendation

The username input validation only checks if it's empty (line 202-205), but doesn't validate that it contains valid characters for a Matrix ID. Matrix usernames have specific character restrictions (typically lowercase letters, numbers, hyphens, underscores, periods).

If a user enters invalid characters (like spaces, uppercase letters, or special characters), the resulting Matrix ID @${username}:${domain} may be invalid and authentication will fail with a confusing error.

Consider adding validation for the username format:

• Check for invalid characters
• Suggest converting to lowercase
• Provide helpful error messages about what characters are allowed

This would improve the user experience by catching errors early during profile creation.

The regex pattern for finding boxel processes could potentially match unintended processes. For example, if a user has a file or directory named "boxel" in their path, or if there's another tool with "boxel" in its name, this could incorrectly match those processes. The pattern [[:space:]]boxel[[:space:]] helps but may still match false positives.

Consider adding additional safety checks:

1. Verify the process is actually a node/tsx process
2. Check that the executable path contains the expected boxel CLI location
3. Add a dry-run mode to show what would be killed before actually killing processes

This would make the command safer and more predictable.

The git status parsing uses line.substring(0, 2) and line.substring(3) to extract the status code and filename. This assumes the git status format is always consistent, but git status can have variations:

1. If a file has spaces in its name and is quoted by git (e.g., "file name.txt"), the substring(3) will include the quotes
2. For renamed files with ->, the parsing handles this, but the substring index could be off if git quotes the filenames

Consider using git status --porcelain=v1 (explicit version) and handling quoted filenames properly by checking if the filename starts with a quote and parsing accordingly. Git uses C-style quoting for filenames with special characters.

This is a minor edge case but could cause issues with files that have unusual names.

Unused function scanWorkspaceForChanges.