Improve GitHub implementation and state detection (#3)

* Checkpoint

* Checkpoint

* Checkpoint

* Checkpoint

* Checkpoint

* Checkpoint

* Checkpoint

* Checkpoint

* Pushing to github works

* Sync with inotifywait + rsync

* Checkpoint

* Checkpoint

* Gitignore works

* Fix running setup commands

* Checkpoint

* Checkpoint

* Checkpoint

Author: osolmaz

.gitignore

@@ -6,4 +6,141 @@ dist/
 .DS_Store
 claude-sandbox.config.json
 !claude-sandbox.config.example.json
-reference-repos/
+reference-repos/
+scratch/
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+lerna-debug.log*
+.pnpm-debug.log*
+
+# Diagnostic reports (https://nodejs.org/api/report.html)
+report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+*.lcov
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (https://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+# Snowpack dependency directory (https://snowpack.dev/)
+web_modules/
+
+# TypeScript cache
+*.tsbuildinfo
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Optional stylelint cache
+.stylelintcache
+
+# Microbundle cache
+.rpt2_cache/
+.rts2_cache_cjs/
+.rts2_cache_es/
+.rts2_cache_umd/
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# Yarn Integrity file
+.yarn-integrity
+
+# dotenv environment variable files
+.env
+.env.development.local
+.env.test.local
+.env.production.local
+.env.local
+
+# parcel-bundler cache (https://parceljs.org/)
+.cache
+.parcel-cache
+
+# Next.js build output
+.next
+out
+
+# Nuxt.js build / generate output
+.nuxt
+dist
+
+# Gatsby files
+.cache/
+# Comment in the public line in if your project uses Gatsby and not Next.js
+# https://nextjs.org/blog/next-9-1#public-directory-support
+# public
+
+# vuepress build output
+.vuepress/dist
+
+# vuepress v2.x temp and cache directory
+.temp
+.cache
+
+# vitepress build output
+**/.vitepress/dist
+
+# vitepress cache directory
+**/.vitepress/cache
+
+# Docusaurus cache and generated files
+.docusaurus
+
+# Serverless directories
+.serverless/
+
+# FuseBox cache
+.fusebox/
+
+# DynamoDB Local files
+.dynamodb/
+
+# TernJS port file
+.tern-port
+
+# Stores VSCode versions used for testing VSCode extensions
+.vscode-test
+
+# yarn v2
+.yarn/cache
+.yarn/unplugged
+.yarn/build-state.yml
+.yarn/install-state.gz
+.pnp.*

CLAUDE.md

@@ -78,3 +78,17 @@ The tool looks for `claude-sandbox.config.json` in the working directory. Key op
 - `volumes`: Additional volume mounts
 - `allowedTools`: Claude tool permissions (default: all)
 - `autoPush`/`autoCreatePR`: Git workflow settings
+
+## Development Workflow
+
+Start a new sandbox:
+
+```
+claude-sandbox start
+```
+
+Kill all running sandbox containers:
+
+```
+claude-sandbox purge -y
+```

README.md

@@ -63,6 +63,7 @@ claude-sandbox
 ```
 
 This will:
+
 1. Create a new branch (`claude/[timestamp]`)
 2. Start a Docker container with Claude Code
 3. Launch a web UI at `http://localhost:3456`
@@ -71,13 +72,17 @@ This will:
 ### Commands
 
 #### `claude-sandbox` (default)
+
 Start a new container with web UI (recommended):
+
 ```bash
 claude-sandbox
 ```
 
 #### `claude-sandbox start`
+
 Explicitly start a new container with options:
+
 ```bash
 claude-sandbox start [options]
 
@@ -90,7 +95,9 @@ Options:
 ```
 
 #### `claude-sandbox attach [container-id]`
+
 Attach to an existing container:
+
 ```bash
 # Interactive selection
 claude-sandbox attach
@@ -103,7 +110,9 @@ Options:
 ```
 
 #### `claude-sandbox list`
+
 List all Claude Sandbox containers:
+
 ```bash
 claude-sandbox list
 claude-sandbox ls        # alias
@@ -113,7 +122,9 @@ Options:
 ```
 
 #### `claude-sandbox stop [container-id]`
+
 Stop containers:
+
 ```bash
 # Interactive selection
 claude-sandbox stop
@@ -126,7 +137,9 @@ claude-sandbox stop --all
 ```
 
 #### `claude-sandbox logs [container-id]`
+
 View container logs:
+
 ```bash
 claude-sandbox logs
 claude-sandbox logs abc123def456
@@ -137,14 +150,18 @@ Options:
 ```
 
 #### `claude-sandbox clean`
+
 Remove stopped containers:
+
 ```bash
 claude-sandbox clean
 claude-sandbox clean --force  # Remove all containers
 ```
 
 #### `claude-sandbox config`
+
 Show current configuration:
+
 ```bash
 claude-sandbox config
 ```
@@ -232,6 +249,7 @@ claude-sandbox --web
 ```
 
 This will:
+
 - Start the container in detached mode
 - Launch a web server on `http://localhost:3456`
 - Open your browser automatically

TODO.md

@@ -2,6 +2,13 @@
 - [x] There is too much orchestration overhead to manage locally, so we need a UI to control, view, and do stuff outside of the container. The best thing is probably to create a web UI to be run locally, and the user will be redirected to this UI when they start a web app locally.
 - [x] Flag for including vs not including non-tracked files
 - [x] Specify with a flag which branch to switch to on container start
-- [ ] Create listener for Claude turn end, to commit, push and create a PR
-  - [ ] GH token should not be copied into the container, huge security risk
-- [ ] Being able to specify which setup commands to run before and after the copying of Git files.
+- [x] Create listener for Claude turn end, to commit, push and create a PR
+  - [x] GH token should not be copied into the container, huge security risk
+- [ ] Being able to specify which setup commands to run before and after the copying of Git files.
+- [ ] Being able to specify a PR to checkout the sandbox from
+- [ ] Reattaching to a running or stopped sandbox consistently, without losing work
+- [ ] More consistent pushing of changes to GitHub
+- [ ] How should we deal with it if the local shadow repo falls behind the remote branch? Options:
+  - a. Let user merge changes from remote to local: We would need to implement a conflict resolver somehow.
+  - b. If conflicts arise, we could just block the operation and let user dump the current state in order not to lose work. This is the simplest option.
+  - Either way, we need to think about how to apply new commits from the remote, because changes currently only flow from the sandbox to the shadow repo.