Each project should have its own FTP/SFTP account
ChatCode allows one physical server to serve multiple projects, but each deployment binding is still explicitly tied to one project. The safest setup is a separate remote account and access directory for each project.
Uploading, overwriting, renaming, or deleting server files can change a live system immediately, and not every action can be reversed. If one FTP/SFTP credential can access multiple websites or directories, a wrong path can deploy project A's code into project B.
Rules enforced by ChatCode
The AI only sees remote profiles attached to the project it is currently working on. Profiles from other projects are hidden from tool lists to reduce accidental selection.
If you deliberately attach an existing server to a second project, ChatCode requires a warning confirmation. A separate binding is created for the new project, with AI permissions disabled by default until you enable them.
Recommended configuration
- Create a separate FTP/SFTP account for each project, for example shop-deploy and api-deploy.
- Set the account home/chroot to the exact deployment directory for the project, rather than giving access to the entire hosting environment when unnecessary.
- Prefer SFTP or FTPS. FTP typically does not encrypt usernames, passwords, or data in transit.
- Do not use root/admin for routine deployments. Grant read/write access only to directories that actually require it.
- Enable SSH command only for projects that need server-side commands; FTP/FTPS profiles do not have a shell.
- Use clear profile names, for example Shop · Production, Shop · Staging, and avoid generic names such as “Server 1”.
- Keep backups/snapshots before major deployments. ChatCode can reduce wrong-profile selection, but it cannot automatically reverse every change written to an external server.
SSH is powerful — use it carefully
When you enable Allow AI to run SSH commands, ChatCode can execute commands on the server using the configured SSH account. If your request is inaccurate, lacks context, or a command has unintended impact, services can fail and data can be changed or lost.
SFTP also runs over SSH but only uses the file-transfer channel. Enabling SSH command is a separate and more powerful permission. If the project only needs file uploads/downloads, keep command execution disabled.
Create a dedicated deployment user that can access only the correct project directory and only the services it truly needs. When mistakes occur, the blast radius is usually smaller.
Do not use root or Administrator with ChatCode unless you fully understand the risk and genuinely need that level of access. A bad command with high privileges can affect the entire server, other websites, services, the firewall, or system data.
A restricted user does not reduce risk to zero. If that user can write to a production website, AI actions can still overwrite files or break the application. Use backups and keep permissions/directories as narrow as practical.
Does the AI know my password or private key?
Passwords/private keys are stored locally by ChatCode on your device and used internally when ChatCode connects to the remote server. AI tools receive only required metadata such as profile name, protocol, project, and operation results; credentials are never returned to the AI.
Remote AI actions depend on the permissions you enable for each binding/project. File transfer and SSH command execution are separate permissions. For operations ChatCode identifies as high risk, the app requires a separate sensitive confirmation before execution.
This reduces credential-exposure risk but does not replace proper server access management. If an account has overly broad permissions, valid actions through ChatCode can still have broad impact.
Checklist before enabling SSH commands
- Confirm the correct project and the correct server profile.
- Use a dedicated deployment user instead of root/Administrator whenever possible.
- Restrict home/chroot, filesystem permissions, and sudo rules to what is actually needed.
- Verify backups/snapshots before important production changes.
- Give the AI a precise objective; avoid vague requests such as “fix the whole server” or “clean everything up”.
- Before commands that change data, run migrations, delete files, or restart important services, review the command and its scope.
- If you do not need a shell, disable SSH commands and keep only file-transfer permission.
When is sharing one FTP/SFTP account acceptable?
Sharing can be reasonable when multiple projects genuinely deploy through the same account or infrastructure and you understand that credential's permission scope. ChatCode allows this configuration for specialized environments.
A leaked credential or incorrect deployment path has a wider impact. If separate accounts are possible, separate them.
Attach an existing server to another project
- Open Remote / Deploy.
- Chọn rõ target project.
- Trong mục Attach existing server, chọn server từ project khác.
- Read the warning and confirm only if you truly intend to reuse the same credential.
- After attaching, verify the host, protocol, username, and project shown on the card.
- Bật Allow AI file transfer for the new binding only after you are sure. This permission is disabled by default on a newly shared binding.
Pre-deployment checklist
Especially when production hosting contains multiple websites, verify the target project and remote path before allowing AI uploads. Separate per-project accounts can turn a path mistake into a permission denial instead of overwriting another website.