
Local AI-agent observability needs a rollback path
In short: Project Telescope observes AI-agent tool traffic at the MCP boundary. Pin the experimental release, snapshot configs, and prove rollback before letting a proxy rewrite your setup.
bash ▸ set -euo pipefail
umask 077
mode=${1:?use snapshot or check}
config=${2:?provide an absolute config path}
backup=${3:?provide a private backup directory}
if [[ "$config" != /* || ! -f "$config" || -L "$config" ]]; then
exit 2
fi
case "$mode" in
snapshot)
mkdir "$backup"
cp "$config" "$backup/original"
cmp -s "$config" "$backup/original"
;;
check)
cmp -s "$backup/original" "$config"
;;
*) exit 2 ;;
esacOne tele setup command can rewrite MCP configurations for four clients: Copilot, Claude Desktop, Cursor and VS Code. That is the behaviour documented in Project Telescope's v0.6.4 README. A tool introduced to observe your agent has become part of its execution path.
My editorial rule is to review that change as a configuration migration: pin the release, preserve every affected configuration and compare the files after undo. A successful rollback command is not the same evidence as a restored setup. The technique below checks that narrower promise; it is not a Telescope deployment benchmark.
Why the MCP boundary is a practical observation point
The versioned proxy documentation describes wrapping server commands with tele proxy to capture JSON-RPC traffic. That is a useful observation point: the request and response cross a boundary the proxy can see.
That gives you a common question to answer: which tool was called, with what request, and what came back? It does not by itself tell you whether the agent made a good decision. It gives the trace needed to ask that question honestly.
Snapshot before tele setup
The same README documents tele setup --undo as the restoration command. Before trying it, use a disposable machine or OS account with synthetic configurations. Inventory every configuration the selected release may change, including files that do not exist yet. A Cursor-only backup is not enough for a multi-client rewrite.
For each existing regular file in that inventory, this Bash helper creates a private, separate backup and later checks byte equality. Save it as config-check.sh. It deliberately fails on missing files, symlinks and reused backup destinations instead of hiding a failed backup:
set -euo pipefail
umask 077
mode=${1:?use snapshot or check}
config=${2:?provide an absolute config path}
backup=${3:?provide a private backup directory}
if [[ "$config" != /* || ! -f "$config" || -L "$config" ]]; then
exit 2
fi
case "$mode" in
snapshot)
mkdir "$backup"
cp "$config" "$backup/original"
cmp -s "$config" "$backup/original"
;;
check)
cmp -s "$backup/original" "$config"
;;
*) exit 2 ;;
esac
Call bash config-check.sh snapshot /absolute/config.json /private/backup-one before the migration, and replace snapshot with check after undo. Use a different backup directory per file. For paths absent beforehand, separately assert they remain absent afterwards. Stop clients while comparing so another writer cannot invalidate the result. This is a content check, not a permissions, ownership or service-health check.
Do not paste an installation command into this test. The v0.6.4 installer also manages binaries and shell configuration; copying MCP files cannot reverse those changes. Select and verify the exact installed binary separately. Merely downloading an archive does not make a bare tele invocation use it.
Local does not mean automatically safe
The v0.6.4 privacy section describes user-scoped SQLite storage under ~/.telescope and no network egress. That is a version-specific project claim, not an independent traffic audit or a guarantee about later releases. My judgement: inspect captured fields using synthetic prompts before collecting customer material. Keep configuration backups private too; they can contain credentials.
Verify restoration before adding a collector
After byte equality passes, restart the client and repeat a harmless tool call without the proxy. File restoration alone cannot prove the original integration still works. Only then compare a synthetic call through the proxy and inspect its recorded events. These Telescope steps are source-derived instructions, not an integration test executed for this article.
What's in it for you
- Detect an incomplete rollback instead of trusting a successful exit code.
- Keep installation changes, configuration restoration and working tool calls as separate checks.
Observability is useful only when you can turn it off, restore the old config, and still explain what the agent did.


