Project Info
Inspiration
I have been running OpenClaw for a while, and I love it. Somewhere in the middle of that, I kept thinking about my mom. She is exactly the person who would benefit from an assistant like this. She juggles appointments and emails from doctors' offices, and she would rather ask a question in one chat than open five apps. She has told me more than once that she never knows what message these AI tools are going to send. She wishes they would simply show her what they are going to do before doing it. That sentence stuck with me. It is basically the whole product. The creator of OpenClaw has written that the real goal is an agent even his mum could use, and that getting there requires much more thought about safety. My mom was asking for the same thing in her own words. Build Week felt like the right week to attempt the safety part. I could not actually give her my setup. I was not comfortable letting the same process hold access to her real accounts, make a change, and then tell her whether it worked. Build Week therefore became one question. What would an assistant have to look like for me to genuinely hand it to my parents?
What it does
Maya talks naturally with a real OpenClaw assistant in Telegram. It can answer bounded questions about her calendar and inbox without making her approve harmless reads. OpenClaw never receives her Google Calendar, Gmail, or family messaging credentials. Those live in a separate process called Bander, which also has its own visible Telegram identity. When something real should happen, such as moving an appointment, replying to the doctor's office, or notifying a family member, Bander shows one Card containing exactly what will happen. That includes the Calendar change, email recipient and reply, or sentence the family member will receive. Nothing happens until Maya taps yes. Approval is not a blank check. Bander pins the deal to the state Maya saw. If the Calendar event or email thread changes before execution, Bander refuses rather than acting on stale information. If a provider's response is lost and the outcome cannot be confirmed, Bander says exactly that. It performs no blind retry and never turns uncertainty into a false success. OpenClaw already has useful approvals, and I did not want to pretend otherwise. The difference is where the keys live. With Bander, the assistant can ask for something, but it cannot hold the Google credentials, rewrite the approved action, or speak as the system that carried it out. The family destination and the text sent to it also belong to Bander, not the model. The Sol variant of GPT 5.6 solved the language problem. It understood requests such as moving a dentist appointment and letting a son know as one bounded request. Bander still owned every identity, parameter, credential, and decision about whether anything could happen. How I built it Codex was my implementation and verification partner throughout Build Week. We worked in a loop I became slightly obsessed with. Write the test for a safety property, observe it fail, implement the smallest correct behavior, and then deliberately break the guard to prove the test could catch the real defect. That process is recorded in BUILD_WITH_CODEX.md. It includes the failures, live discoveries, deliberate mutations, and the evidence after each fix. Codex helped me move much faster across the broker, integrations, tests, setup flow, sandbox, and documentation. I still made the calls that shaped the product. Reads would remain easy. Real consequences would require an exact deal. Credentials and outcomes would stay outside the assistant. If an API could not support honest recovery, I would not build that feature. The stack combines OpenClaw and GPT 5.6 Sol for conversation and bounded tool selection with a TypeScript broker holding separate Google Calendar, Gmail, and Telegram credentials behind five bounded MCP tools. The hosted browser experience runs the same authority engine against clearly disclosed seeded data. Judges can experience its approval, refusal, replay, and uncertainty behavior without creating accounts. The complete source, setup guide, evaluator paths, and evidence are in the public repository. Challenges I ran into My assumptions kept being wrong, and the test first loop kept catching them. I originally designed Gmail recovery around caller supplied message identifiers. The first live test showed that Gmail rewrites them. The recovery design was dead on arrival. We rebuilt it around an opaque Bander header bound into the approved email. Recovery now performs one bounded search of Sent mail. It either finds an exact match or reports the result as unconfirmed. The first live compound approval also exposed a state lock deadlock after the user approved a Calendar change and family update. The design looked sound in isolation. The continuous real path proved otherwise. We fixed it and added a permanent regression test. Another review caught Bander about to report that nothing changed in a case where Google might actually have committed the operation. That one scared me. The entire product is supposed to tell the truth about what happened, and it nearly shipped with a lie. We changed the outcome model so an unconfirmed result stays unconfirmed, including on replay. Bander now tells the parent to check instead of turning missing evidence into a confident answer. Accomplishments that I am proud of The Google, Gmail, and Telegram behavior shown in the film is real. The Calendar changes against a dedicated Google account. Gmail places the approved reply in Sent. A second phone shows the exact family update Maya approved. The changed world refusal also runs against real Calendar state. Bander moves nothing and sends no family message. The published product matrix contains 535 functional cases plus 26 adversarial cases. The evidence ledger records the critical properties we observed failing before their fixes. It also records deliberate mutations that prove the corresponding regression tests can fail. There is also a hosted browser experience that runs the shared authority engine against explicitly seeded data. It lets a judge experience all 27 deterministic outcomes, including decline, replay, changed world refusal, and truthful uncertainty, without trusting Bander with an account. What I learned The thing I did not expect is that truthfulness decides which features you are allowed to build. Calendar and Gmail made the cut because their APIs let Bander pin identity and inspect what actually happened. Restaurant reservations, smart home control, calling the clinic, and several other ideas did not. I wanted all of them, but I cut them because I could not make their recovery stories honest. Saying no to features became part of the design. I also learned that writing for my mom is harder than writing code. A technical precondition failure became a plain sentence explaining that her Calendar had changed since she asked, so Bander moved nothing and sent nothing. That rewrite required as much care as the logic underneath it. What is next for Bander Today Bander is a product that a technical family member sets up once for someone they love. Setup takes about 45 minutes, is reversible, and runs through an isolated OpenClaw profile without modifying an existing installation. Next is reducing that setup friction without weakening the boundary. That means guided onboarding, hosted setup, durable authority for actions already in progress, and additional domains only when their APIs permit honest recovery. Next I want to put Bander in front of a parent, stay quiet, and watch where they hesitate. If they misunderstand who can act, what approval means, or what the family member sees, I will treat that as a problem with Bander rather than a problem with the person using it.
Bander
The OpenClaw I’d actually give my parents.
Your assistant can read your calendar and mail and talk like a person. Bander holds the keys—calendar changes, email replies, and family messages happen only as exact deals you approve, and Bander reports only what it can prove.
▶ Try Bander in your browser — no accounts, nothing real can happen
The browser is a deterministic, seeded product experience. It cannot contact Google, Gmail, Telegram, OpenAI, OpenClaw, or your accounts.
Demo
- Watch: https://www.youtube.com/watch?v=z7OrvquejvQ
- Try: https://gowtham0992.github.io/bander/
- Source: https://github.com/gowtham0992/bander
Judge quickstart
npm ci && npm run demo
# Open http://127.0.0.1:4310 — 27 deterministic outcomes
npm run verify:demo
# Verifies all 27 outcomes without accounts or credentials
The supported Node floor is 22.12.0; CI and the repository-pinned runtime use Node 24. In the clean-clone verifier, both measured warm-cache runs completed in 13 seconds on the development machine. Package and network download speed are the main variables, so this is measured evidence rather than a fixed-time promise. Expected output ends with 27 of 27 demo outcomes passed. No shared judge account is provided because shared credentials would contradict Bander’s trust model.
For Build Week judges
Category: Apps for Your Life
The required /feedback Codex Session ID is supplied through Devpost.
The 30-second story
- Mum asks what is coming up tomorrow. OpenClaw answers conversationally. No Card and no approval toll.
- She asks to reply to an email. Bander shows the recipient and exact email reply before anything is sent.
- She approves once. Bander sends only those stored bytes.
- She asks to add the appointment and tell a connected family member. One Card shows the Calendar change and the exact sentence Bander may send them.
- After approval, Bander changes the Calendar first, then sends that family member precisely the sentence Mum approved. If the Calendar or email changes before approval, Bander stops.
Real product, fictional data
The browser experience uses seeded data and cannot contact real services. Bander’s real Telegram, Google Calendar, Gmail, OpenClaw, and GPT‑5.6 integration using fictional test data was exercised end to end. The evidence ledger records the corresponding live runs and failure-first verification.
Why not just native approvals?
OpenClaw’s approvals are useful, and Bander does not replace them. They gate what a credential-holding process may do. Bander moves the credentials themselves—Calendar, Gmail, and its Telegram identity—outside the reasoning agent.
Every approval binds to rechecked world state, such as a Calendar ETag or the newest message in an email thread. Bander executes the stored bytes and reports only observed results from an identity the model cannot speak through.
When Gmail’s response to a send was lost, Bander reported the result as unconfirmed and provably did not send again. That behavior—not the approval button—is the product.
This boundary applies to the dedicated Bander-protected OpenClaw profile. It does not protect a machine already compromised at the operating-system or user-account level, and it does not restrict the owner’s other agents or applications.
Two identities, one clear boundary
OpenClaw is the conversational assistant. It can answer bounded schedule and inbox questions and ask Bander to prepare a deal. Bander is the separate guardian identity: it holds the Google and Telegram credentials, shows the exact human approval surface, performs the stored action, and reports the observed outcome. OpenClaw cannot speak through Bander.
flowchart LR
P["Parent in Telegram"] --> O["OpenClaw<br/>conversation"]
O -->|"5 bounded tools"| B["Bander<br/>keys + exact deal"]
B -->|"minimal status"| O
B -->|"Card + outcome"| P
B -->|"conditional action"| G["Google Calendar / Gmail"]
B -->|"exact approved update"| F["One paired family member"]
What a parent can do
- Ask what is on the calendar without approving a read.
- Read one matching email without approving a read.
- Add, move, or remove one narrowly eligible Calendar event.
- Approve one exact plain-text reply to a resolved email thread.
- Approve an exact family update to one consented family member.
- Say Not now or receive a truthful stop when the world changed.
- See an unconfirmed result described honestly, without a blind repeat.
The real product currently supports ordinary OpenClaw conversation; bounded primary-Calendar reads of at most 31 days and 50 sanitized events; bounded Gmail inbox reads; one timed default Calendar creation with a disclosed 60-minute default or explicit 15-minute-to-12-hour duration; one exact eligible-event reschedule or cancellation under its ETag; one exact plain-text Gmail reply; and one deterministic Telegram family update bound to the single active consented contact.
Writable Calendar events must be on primary, timed, non-recurring, default type, owner-organized, attendee-free, and exactly resolved. Creation adds no attendees, recurrence, location, description, conferencing, attachments, custom reminders, or reservation. Gmail excludes spam/trash and never adds recipients, reply-all, forwarding, attachments, or arbitrary outbound threads. Bander does not make reservations, purchases, medical decisions, transportation changes, or smart-home changes. Standing autonomy is demonstrated only in the deterministic sandbox.
The real protected OpenClaw profile exposes exactly five tools:
bander__list_capabilitiesbander__read_schedulebander__read_inboxbander__propose_actionbander__get_receipt
gpt-5.6-sol may extract bounded language hints. Deterministic Bander code chooses identities, versions, final intervals, recipients, routing, rendered messages, MIME, execution parameters, authority, and outcomes.
How Codex and GPT‑5.6 Sol were used
Codex was the primary implementation and verification partner. The build proceeded in bounded slices: observe the load-bearing behavior fail, implement the narrow fix, then deliberately mutate critical guards to prove the regression tests could catch the real defect. Codex accelerated the authority engine, Google and Telegram integrations, browser sandbox, repository-local setup flow, tests, and documentation. The evidence ledger names the properties actually observed red; it does not claim every static test failed first.
The human chose the product boundary. Credentials and outcomes remain outside the reasoning agent. Reads are toll-free; consequential effects become exact approved deals. OpenClaw and Bander are visibly separate Telegram speakers. Eligibility stays narrow. Standing authority remains sandbox-only. Bander refuses to fake reservations, smart-home actions, or scam detection. Every public capability claim was reviewed against observed behavior.
Iteration changed the product. Live work showed that Gmail rewrote the caller-supplied Message-ID; the first compound approval exposed a state-lock deadlock; and an ambiguous Calendar execution was initially about to be described as “nothing changed.” The setup path and public sandbox were repeatedly compared with actual runtime behavior rather than accepted from generated prose.
Our live probe suites passed 49 natural and adversarial cases, with zero false accepts in those runs. That solved the understanding. It did not solve the trust, which is why the rest of this repository exists. In the product, Sol has bounded roles only: GPT‑5.6 Sol operates inside those deterministic boundaries. OpenClaw uses it for conversation and genuine tool selection. Bander uses strict Structured Outputs for bounded Calendar, inbox, reply, and family hints. Sol cannot choose identities, recipient addresses, credentials, authority, execution parameters, or outcome language.
Codex built and tested the system; GPT‑5.6 Sol operates within its deterministic boundaries. The /feedback Session ID from the primary build task will be supplied directly in Devpost, not committed as a placeholder.
Evaluator paths
| Path | What it proves | What it does not prove | Cleanup |
|---|---|---|---|
| 90-second hosted experience | Seeded product story, shared Card/authority behavior, replay, and truthful uncertainty | Live OpenClaw, Google, Gmail, or Telegram access | Close the tab |
| Clone + deterministic verification | Reproducible 27-outcome sandbox and browser/server parity from the lockfile | A live external-service mutation | Ctrl-C; optionally remove the clone |
| Optional real setup | The bounded real path with the evaluator’s disposable test accounts | Broad OAuth onboarding or modification of an existing OpenClaw | Follow selective recovery in SETUP.md |
Real services and evidence
- Architecture decisions
- Real Calendar boundary
- Schedule read lane
- Family pairing and replay-safe delivery
- Calendar creation and cancellation
- Gmail and direct-family coordination
- Browser product surface
- Guided setup and recovery
- Judge-facing product surface
The latest verified product matrix covers 535 functional cases plus 26 adversarial cases. Load bearing safety properties were observed failing before their fixes. The ledger identifies those specific red→green cases rather than claiming that every safety property failed first.
Guided real setup
The complete adult-child setup, BotFather privacy checks, Google Desktop OAuth steps, remote family invitation, doctor, and recovery paths live in SETUP.md.
npm ci
npm run setup
# Follow the repository-local guide and edit the ignored .env yourself.
npm run doctor
npm run doctor -- --live
npm run real
npm run setup is a repository-local setup guide and verifier, not an installer. It never reads or modifies ~/.openclaw; npm run real launches repository-pinned OpenClaw 2026.7.1 in an isolated generated home. Setup does not collect or print secrets.
Supported and empirically verified: macOS on Apple Silicon; Node 22.12.0 or newer; Node 24 in CI and the pinned child runtime; repository-pinned OpenClaw 2026.7.1; two Telegram bots and one private group; a dedicated Google OAuth Desktop client in External/Testing mode with configured test accounts; and a modern evergreen browser for the sandbox.
Expected but unverified: Intel macOS and Linux deterministic sandbox/tests.
Unsupported: Windows real mode, Docker, remote/headless production deployment, other OpenClaw versions, additive modification of an existing OpenClaw, and restart-durable production authority. Broad production-grade OAuth onboarding for arbitrary public accounts is unsupported.
Deterministic browser sandbox
The hosted and local browser experiences use the shared production authority engine, contracts, canonical SHA-256 hashing, and Card renderer against versioned fictional fixtures. They never claim to touch real services.
npm run demo
npm run verify:demo
npm run build:pages
npm run verify:pages
npm run verify:pages is the single artifact-security, direct-refresh, and browser/server parity command. Its CSP uses connect-src 'none'; the artifact excludes server, OAuth, Telegram, OpenAI, OpenClaw, filesystem, and process-environment modules. Deployment uses the official Pages Actions workflow.
Verification
npm run check
npm run attack
npm run verify:demo
npm run verify:clean-clone
npm run verify:pages
npm run verify:recovery
npm run verify:standing-recovery
npm run verify:openclaw
npm run verify:read-sol
npm run verify:gmail-sol
npm run verify:create-sol
npm run verify:cancel-sol
npm audit
Real-service evidence commands are documented in SETUP.md and the evidence ledger; they are not part of the zero-account judge path.
Security boundary and limitations
In the Bander-protected OpenClaw profile, the model can converse, read bounded schedule and inbox DTOs, and propose through five bounded Bander tools. It does not receive Google credentials or family routing, cannot approve its own proposal, and cannot author Bander’s Card or outcome. Bander does not protect a host already compromised at the operating-system or user-account level.
- Bander does not provide full Calendar management. Writable actions accept only the narrow event shapes above.
- Schedule and inbox facts intentionally enter the model trajectory so it can answer the parent. Descriptions, Calendar identifiers, ETags, credentials, Cards, callbacks, family routing, and Bander outcomes do not.
- Calendar titles and email text are untrusted data. Sanitizing and quoting them reduces but does not eliminate model prompt-injection risk.
- Gmail may rewrite Message-IDs. Ambiguous sends are reconciled by one opaque Bander header plus exact stored fields and are never resent automatically.
- Telegram has no client idempotency key. A confirmed response means Telegram accepted the message, not that the family member read it. An ambiguous family transport result remains unconfirmed and is not retried.
- Real authority state is process-local and not restart-durable. Telegram installation and delivery state are file-backed; the deterministic sandbox contains the broader recovery demonstrations.
- The loopback-only MCP endpoint is unauthenticated and must not be exposed to a LAN or the public internet.
- The strong route claim applies only inside the dedicated protected profile and effects routed through Bander. Other agents, applications, credentials, and same-host compromise remain outside the claim.
License and public links
Bander is available under the MIT License.
Analysis
View
Metric
- 61
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- CSSIn code
- HTMLIn code
- OpenAIIn code
- ReactIn code
- TypeScriptIn code
- Node.jsClaimed
5 of 6 appear in the indexed code. 1 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
1.7 MB
Source files
162
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
gowtham0992/bander
215 files · 10.3 MB · @ 9347e72
Structure
Interface
1 file · 0%Screens, components and styles rendered to the user.
Application logic
53 files · 25%Domain rules, services and shared utilities.
+2 more
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- TypeScript80%
- Markdown16%
- CSS4%
- HTML0%
- YAML0%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
apps/broker/package.json
npm · 9- @bander/contracts
- @bander/core
- @bander/demo-sandbox
- @fastify/static
- @modelcontextprotocol/sdk
- fastify
- googleapis
- openai
- zod
apps/web/package.json
npm · 9- @bander/contracts
- @bander/core
- @bander/demo-sandbox
- react
- react-dom
- +4 more
package.json
npm · 77 development-only dependencies.
apps/mock-services/package.json
npm · 2- @bander/contracts
- fastify
packages/core/package.json
npm · 2- @bander/contracts
- @noble/hashes
packages/demo-sandbox/package.json
npm · 2- @bander/contracts
- @bander/core
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.