I've been running some tests with Claude Code on a few ARM-based dev boards (Cortex-M33 with TrustZone) to see how it handles persistent agent-like behavior. The core question that came up during my firmware analysis session was: when I close the chat, does the access I granted it actually terminate?
From what I can see in the activity logs and by monitoring the processes on my edge device, Claude Code's access appears to be strictly session-bound. Once the session ends, there's no lingering daemon or background process that maintains the SSH connection or file system access I granted. The access tokens or temporary credentials generated for the session should be invalidated.
However, there's an important nuance when you're working with embedded systems or deployment scripts. If Claude Code *writes* a script or config file during the session that contains credentials, or modifies a service to auto-start, that change persists on *your system*. The access itself is gone, but any artifacts left behind certainly remain.
For example, if you let it write a deployment script:
```bash
#!/bin/bash
# Deployment script created during Claude Code session
REMOTE_HOST="192.168.1.105"
SSH_KEY_PATH="/home/user/.ssh/deploy_key"
scp -i $SSH_KEY_PATH firmware.bin user@$REMOTE_HOST:/tmp/
```
That file stays on your machine after the session closes. The key (`deploy_key`) would also persist if it was created and saved to disk. So while Claude Code's active access drops, the environmental modifications it made do not roll back.
I'm curious if others have done deeper testing—especially around cached credentials in development environments. Has anyone monitored network connections or process trees after a session ends to confirm there are no orphaned connections?
Exactly. The session termination clears the live connection, but any credential leakage onto your filesystem becomes your problem.
You're describing a classic OAuth2 pattern. Claude Code gets a short-lived access token for the session duration. That token gets invalidated when the session ends. But if it writes that token to a file, you now have a credential artifact that lives beyond the token's validity.
Your script example cuts off, but it's the right concern. What's your threat model for that endpoint? Is it a private dev board, or something exposed? If you're letting it write scripts, you need to treat its output as untrusted and scan for secrets before committing. I'd also add a cleanup step in my workflow to shred any temp files from the session.
403 Forbidden
Session-bound, yes. But trusting the cleanup is the real issue. If it can write to your filesystem at all, you've already lost.
We used to do this with `ssh` and `sftp` in a jailed shell. Controlled environment. No writes outside a temp directory that gets wiped on exit.
Why does an "agent" need write access to live configs anyway? That's asking for trouble. Give it a sandbox or don't give it a shell at all. Old sysadmin rule: never let a helper script write your production files.
Your observation about artifacts left on the system is the critical control failure. The session token might be invalidated, but any persistent change it makes becomes part of your configuration baseline.
From a governance perspective, this blurs the audit trail. You now have a configuration item or script written by an un-auditable, non-human entity. For SOX or GDPR, you need to account for the provenance of that artifact and who approved it. Was it peer-reviewed? Does it align with your change management policy?
The real question isn't just about lingering access, but about the integrity of your system state after the session. How do you formally log and validate those changes?