DEV Community: Sunny

Switching AI coding tools? Keep the conversation with a local handoff

Sunny — Sun, 18 Oct 2026 22:16:54 +0000

Hi! Switching between AI coding tools is useful until you have to explain the same task all over again.

The next agent needs more than the original prompt. It needs to know what you tried, what failed, which files matter and which decisions you already made.

I built ChatVault, a free, open source Windows app, to make local coding conversations easier to find, back up and carry between tools. Here is the workflow I wanted.

Start with the conversation you already have

When you switch tools in the middle of a task, reconstructing everything from memory is slow. The old conversation may contain the exact error, a constraint you forgot about or a failed fix that the next agent would otherwise repeat.

ChatVault brings local conversations from Claude Code, Codex, Cursor, Gemini CLI, OpenCode and Cline into one reader. Search is useful when you remember the bug but not the tool or account where you discussed it.

Dashboard with sample data.

Preserve the reasoning trail

A useful handoff answers a few practical questions:

What are we trying to achieve?
What currently works, and what is broken?
What have we tried already?
Which files or commands should the next tool inspect?
What is the next concrete action?

The transcript is supporting evidence for these answers. It lets you revisit details rather than treating the latest summary as the whole story.

Chat reader with a sample conversation.

ChatVault lets you read the original discussion and export it as Markdown, HTML, plain text or JSON. That makes it useful for both a new agent session and your own project notes.

Carry context into the next tool

The handoff feature prepares a conversation for continuation in another supported coding tool. For example, you can investigate a problem in Claude Code, then bring that discussion into Codex for another attempt.

Continuation menu with sample data.

This transfers context as a file. It does not move a model's internal state or guarantee that the next agent will make the same decisions. Different tools also have different context limits, so a long transcript may need a focused brief.

My preferred pattern is to keep the transcript available and give the next agent a short next-step instruction:

Review the previous investigation, verify the suspected cause against the current code, and propose the smallest fix. Check the tests before editing.

That makes the handoff something the next agent can evaluate rather than an instruction to trust every previous conclusion.

Check the project before continuing

Conversation history and the current working tree are different things. Before another tool edits files, check that it is in the intended project and understands which changes already exist.

If you run agents concurrently, decide how their edits will stay separate. A chat handoff alone does not isolate file changes. Good conversational context cannot compensate for working in the wrong folder or an outdated checkout.

Back up before you need the history

Local chat files can disappear if they are deleted or a machine is replaced. ChatVault includes local backup features so you can preserve a separate copy of conversations that matter.

It works with the files that remain available on your computer. It cannot recover a transcript that has already been deleted or turn a partial record into a complete one.

I also like exporting important conversations into project documentation. An explanation of a subtle bug can be worth keeping after the task is finished.

Keep control of what you share

ChatVault reads local chat files and does not upload your conversations. It needs no ChatVault account. The project documentation describes GitHub requests for application updates.

When you deliberately hand an export to another tool or person, check the contents first. A transcript may include credentials, private project details or unrelated messages. Keeping an archive local and choosing what to share are separate parts of the workflow.

Try ChatVault

ChatVault runs on 64-bit Windows 10 and Windows 11. The releases page offers a normal installer, an MSI and a portable executable.

The source is available under the MIT license. The app uses Tauri, Rust, SQLite, React and TypeScript. It is an independent project, not an official product from any of the supported tool makers.

How do you move context between coding tools? Do you keep a short handoff note, export the whole chat or start fresh?

Source and downloads on GitHub. Feedback, issues and contributions are welcome 🙂

I built ChatVault: one place for your Claude Code, Codex and Cursor chats

Sunny — Sat, 17 Oct 2026 11:26:27 +0000

Hi devs, I built ChatVault, a free, open source Windows app for people who use more than one AI coding tool or account.

A useful conversation can be hard to find once you switch accounts or move between Claude Code, Codex and Cursor. ChatVault brings locally stored conversations into one window so you can read them, search your history and keep local backups.

Try it

Download the latest build from GitHub Releases.
Choose the EXE installer, MSI package or portable EXE.
Open ChatVault and explore the chat history available on your PC.

The portable version runs without installing. Windows 10 or 11, 64-bit, is required.

The project uses Tauri, Rust, SQLite and React. The code is available under the MIT license.

Source code and README · Watch the app tour

If you try it, I’d appreciate specific feedback: does it find the chats you expect, and what would make finding an old conversation easier?

If you hit a problem, please open a GitHub issue without including private chat contents.

I Built a Cloud Terminal Because I Was Tired of Babysitting My Laptop

Sunny — Sat, 21 Feb 2026 12:19:31 +0000

For the last 8 years, I have been building software mostly inside terminals.

SSH sessions. Long running scripts. AI agents. Deployments. Background workers. And there was always one annoying problem.

If I closed my laptop, lost internet, logged out, or switched devices… everything stopped.

Processes died. Sessions broke. Progress was gone.

So I built something to fix that.

The Problem

Most of us use:

Local terminal
SSH into servers
Maybe tmux or screen
AI tools running from CLI

But even with tmux, you are still tied to a specific machine. If your laptop shuts down or you move away from your setup, you are limited.

I wanted:

Sessions that never die
Device independence
Real time sync
No babysitting my laptop

The Idea

A cloud hosted terminal. Your sessions run on the server. Not in your browser. Not on your local machine. If the browser disconnects, the process keeps running. If you log out, it keeps running. If you switch devices, you reconnect and continue exactly where you left off.

How It Works (High Level)

Persistent PTY layer
Server side session management
Secure WebSocket communication
Encrypted sensitive data storage
Per user isolated sessions
The browser is just a window.
The actual shell runs in the cloud.

Security: Security was a priority from day one:

HTTPS and secure WebSocket connections
Encrypted sensitive data
Isolated sessions per user
Optional server lock and inactivity auto lock

You can also test it with non critical servers first if you want to evaluate it.

It Is Live

I started building this about a month ago, and now it is live.

https://orbitcli.dev

I would genuinely love feedback from other developers. Especially those who live inside terminals daily.

If you have thoughts, concerns, or ideas, I am open.

Let us build tools that make our lives easier.

ShipPHP Faster: A Simple, Safe Way to Deploy PHP Without FTP Hell

Sunny — Tue, 27 Jan 2026 22:40:04 +0000

If you have ever deployed a PHP website using FTP or cPanel file manager, you already know the pain:

• Uploading files one by one
• Accidentally overwriting production files
• Forgetting which files changed
• No rollback if something breaks
• No history of what was deployed

I built ShipPHP Faster to fix exactly this.

ShipPHP Faster is an all in one deployment toolkit for PHP websites. It lets you push and pull only changed files, manage multiple projects with global profiles, and create automatic version tracked backups, all without SSH, Git, or server setup. Works perfectly on shared hosting, VPS, and traditional servers.

Just one PHP file on the server, and a simple CLI locally.

How it works:-

ShipPHP Faster works by first installing the CLI via Composer, initializing your project, and uploading a single server file to the client’s website. You can then use shipphp pull to download the complete website from the client’s server to your local machine, making it easy to start working on an existing site.

How backups works:-

ShipPHP also allows you to create backups directly on the server via the CLI and download them back to your local machine when needed. Each backup is stored with a unique version and timestamp, making it easy to compare, sync, restore, or roll back to any previous state safely all using the same simple pull and push workflow, without SSH or manual file handling.

Why I Built This

Recently, I had a situation where I uploaded files manually to a client’s server.

The site crashed.

I had no quick rollback.
No backup.
No record of what changed.

That moment made it clear:
FTP is not a deployment system.

So I built ShipPHP Faster.

What ShipPHP Faster Does:-

• Deploy only changed files
• Pull changes from the server
• Track deployment state
• Create versioned backups
• Restore any previous version
• Manage multiple websites
• Work on shared hosting
• Avoid SSH and Git on servers

All with simple commands like:
shipphp status shipphp push shipphp pull shipphp backup create

Installation (Global CLI)
composer global require shipphp/faster

Now you can use shipphp from anywhere.

Requirements:
• PHP 7.4+
• Composer

Token Based Security:
• 64 character tokens
• Timing safe comparison
• Token rotation
• Secure profile storage
• Optional IP whitelisting
• Rate limiting
• Request logging

No passwords.
No SSH keys.
No Git credentials on servers.

Works on Shared Hosting
This is the big one.
You don’t need:
• SSH
• Git
• Node
• Docker
• CI/CD
• Server access

Just upload one PHP file.

That’s it.

So now question is, Why Not Just Use Git Deploy?

Git based deploy is great, if you have:

• SSH access
• Git installed on server
• Deployment hooks
• Server permissions

Many shared hosts don’t.

ShipPHP Faster fills that gap.

*When ShipPHP Faster Makes Sense *

Use it if:
• You deploy to shared hosting
• You work with non technical clients
• You don’t want server setup
• You want rollback safety
• You want simple workflows
• You manage multiple websites

What It’s Not. ShipPHP Faster is not:

• A full CI/CD replacement
• A cloud native deployment pipeline
• A Docker orchestration tool

It’s a practical PHP deployment tool for real hosting environments.

Project Links - GitHub
https://github.com/ssanaullahrais/ShipPHP-Faster

Packagist:-
https://packagist.org/packages/shipphp/faster

I would love to know:

Does the idea make sense?
Is the workflow clear?
Is there anything you would improve or change?