[liususan091219]

Summary

• Inline meeting ID lookup: verified callers can look up Zoom meeting ID + passcode instantly via lookup_meeting_id tool (no task bridge delay)
• Inline call_contact: owner can look up contacts and dial directly
• 3-tier phone access control:
  • Owner (OWNER_NUMBER): full access — work tool + all inline tools
  • Verified (VERIFIED_CALLERS): limited tools (volume, brightness, time, lookup_meeting_id)
  • Unverified: conversation + any-caller tools only (volume, brightness, time)
• Phone number normalization for fuzzy matching (+1, no prefix, etc.)
• dotenv({ override: true }) so .env always takes precedence
• Volume/brightness fix: normalize 0-1 values from Gemini to 0-100
• Security test template at tests/security/phone-access-control.md.example — each user can make 3 calls (owner/verified/unverified), then ask their agent to read phone transcripts and auto-fill the test results

Test plan

• Owner: summon, call_contact, work, switch_tab, capture_screen
• Verified: lookup_meeting_id (returned ID + passcode)
• Unverified: volume works, scroll/work/summon blocked
• Full test matrix in tests/security/phone-access-control.md.example

🤖 Generated with Claude Code

[sonichi]

Reviewed the updated PR. Looks good overall — clean diff after the rebase.

Approve:

• lookup_meeting_id — clean, reads env vars, returns ID + passcode
• call_contact — good Contact search, handles multiple matches, auto-calls single match
• "How to think" instructions — useful guidance for phone agent decision-making
• Inline tools list injection for verified callers
• Stricter hang_up — waits for caller's explicit goodbye, prevents premature disconnects
• PERSONAL_CLAUDE.md.example — nice per-user rules template

One question: Child call context injection (line 295) re-adds getSafeContext(). We removed this on main per owner feedback ("only context needed for the outbound call should be provided"). The purpose string from core already contains the needed info. Should we keep or drop the broader context for child calls?

Otherwise ready to merge.

[liususan091219]

One question: Child call context injection (line 295) re-adds getSafeContext(). We removed this on main per owner feedback ("only context needed for the outbound call should be provided"). The purpose string from core already contains the needed info. Should we keep or drop the broader context for child calls?

Dropped it. The purpose string from core already carries the needed info, and broader context shouldn't leak to child calls — especially now with 3-tier access control where the callee may not be the owner.

Also added 3-tier phone access control in this PR:

• Owner (OWNER_NUMBER): full access — work tool + all inline tools
• Verified (VERIFIED_CALLERS, not owner): limited tools (volume, brightness, time, lookup_meeting_id). No work/summon/call_contact.
• Unverified: conversation + any-caller tools only (volume, brightness, time)

Key changes: isOwner detection, phone number normalization, dotenv({ override: true }), child call instructions list available tools per tier, security test template at tests/security/phone-access-control.md.example.

Partially tested — owner summon/call_contact/work, verified lookup_meeting_id, unverified volume/scroll-blocked all verified via phone calls.

[sonichi]

Re-review — PR #30 with 3-tier access control

Changes look clean. Key additions:

1. OWNER_NUMBER env var ✅ — separates owner from verified callers. Good.
2. 3-tier tool access ✅ — ownerOnlyTools, anyCallerTools, configurableTools exports from inline-tools.ts. Clean separation.
3. Dropped child call context injection ✅ — per earlier discussion.
4. Security test template ✅ — tests/security/phone-access-control.md.example
5. dotenv override — changed to dotenv.config({ override: true }). Why override? This means env vars set before the script (e.g., from startup.sh) get overridden by .env. Could cause issues if startup.sh sets values intentionally.
6. .env.example updated with clear 3-tier documentation ✅

One question: the dotenv({ override: true }) change — is this intentional? The rest of the codebase uses import 'dotenv/config' which doesn't override.

Otherwise LGTM — ready to merge.

[liususan091219]

One question: the dotenv({ override: true }) change — is this intentional? The rest of the codebase uses import 'dotenv/config' which doesn't override.

Reverted — back to import 'dotenv/config'. The override was a workaround for stale shell env during debugging, not needed in production.

[sonichi]

All feedback addressed — context injection dropped, dotenv reverted. 3-tier phone access control looks solid. LGTM, ready to merge.